From owner-freebsd-ports@FreeBSD.ORG Tue Dec 9 20:03:11 2014 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 995FA4F4 for ; Tue, 9 Dec 2014 20:03:11 +0000 (UTC) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 27D49CAB for ; Tue, 9 Dec 2014 20:03:10 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3jxskz55THz9D for ; Tue, 9 Dec 2014 21:03:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:organization:subject:subject:from:from :date:date:content-transfer-encoding:content-type:content-type :mime-version:received:received:received:received; s=jakla4; t= 1418155385; x=1420747386; bh=c3Ziqoo+qF5/Pz+nOFewQdtFRlZaCdYl2RY Ob8aG9fE=; b=XFs2zSKaVgqR2yU1Lu9mQHe0z9xYbbltMocUQ7liUcw8glCkZ8/ 1N1E5aVN/c/osGyXbeb/0JZSBjm0ERofz8Fj/t8ekl6lKjt/lCZqszNkverz0zh0 NysQayD2aiZXupFKvxR5twnMgixipvtnYD6dCRhaOS+MHQN9iXz+UTj4= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id unWgVkUsWb84 for ; Tue, 9 Dec 2014 21:03:05 +0100 (CET) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP for ; Tue, 9 Dec 2014 21:03:04 +0100 (CET) Received: from neli.ijs.si (neli.ijs.si [IPv6:2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by mildred.ijs.si (Postfix) with ESMTP id 3jxskw468xz5v for ; Tue, 9 Dec 2014 21:03:04 +0100 (CET) Received: from neli.ijs.si ([2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by neli.ijs.si with HTTP (HTTP/1.1 POST); Tue, 09 Dec 2014 21:03:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 09 Dec 2014 21:03:04 +0100 From: Mark Martinec To: ports@FreeBSD.org Subject: The futuire of 'interpreter-based threads' in perl Organization: J. Stefan Institute Message-ID: X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.0.3 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 20:03:11 -0000 Mathieu Arnold wrote in another thread: > Next Perl update, and plans beyond... > As for the plans beyond that I was talking about in the subject, there > will be a Perl 5.22 released next May, (and 5.24 the May after that,) > when that happens, I'll change the default Perl to be 5.20, and > deprecate 5.18 which won't, then, be supported. Sometime at the end of > the summer, like sometime September, I'll change the default Perl to > 5.22 and try to keep it that way, that is, a new Perl goes in in May, > and gets to be the default in September. That reminds me of a question I have been brewing for some time now. As far as I can tell, all four lang/perl5.* ports have by default option THREADS (Build threaded perl) enabled by default. Don't remember when it became a default in ports, must have been at least a year ago. Which is very nice. I got accustomed to it, at our site we have developed a couple of in-house applications that make good use of perl ithreads. In some cases these interpreter threads save a lot of complexity (like managing a herd of cooperating processes, message passing & queueing). The price is a potentially somewhat larger memory footprint (multiple interpreters) and a due care needed when one has to deal with shared variables, locks and queues. All in all, this feature can be very valuable. But now, just as we have started depending on it, the perl docs say (perl5200delta, ): Interpreter-based threads are now discouraged The "interpreter-based threads" provided by Perl are not the fast, lightweight system for multitasking that one might expect or hope for. Threads are implemented in a way that make them easy to misuse. Few people know how to use them correctly or will be able to provide help. The use of interpreter-based threads in perl is officially discouraged. I don't buy arguments 'makes them easy to misuse' and 'few people know how to use them correctly'. Yes, multithreading has its share if implications that require more careful design. But at the same time for certain near-real time applications it can be a very valuable tool. I wonder if FreeBSD has any say in this perl developers decision. And if not, what are the plans to keep compatibility with existing multithreaded applications without being locked down to some stale version of perl. Mark