From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: wip-threads-and-fork Date: Wed, 08 Feb 2012 23:10:47 +0100 Message-ID: <877gzx0ye0.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1328739060 9323 80.91.229.3 (8 Feb 2012 22:11:00 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 8 Feb 2012 22:11:00 +0000 (UTC) Cc: Bruno Haible To: guile-devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Feb 08 23:10:59 2012 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RvFj9-0000FA-FA for guile-devel@m.gmane.org; Wed, 08 Feb 2012 23:10:59 +0100 Original-Received: from localhost ([::1]:44142 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvFj8-0002XV-DG for guile-devel@m.gmane.org; Wed, 08 Feb 2012 17:10:58 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:42069) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvFj4-0002XQ-Qv for guile-devel@gnu.org; Wed, 08 Feb 2012 17:10:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RvFj3-0004Uk-5W for guile-devel@gnu.org; Wed, 08 Feb 2012 17:10:54 -0500 Original-Received: from a-pb-sasl-sd.pobox.com ([74.115.168.62]:53863 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvFj3-0004Uf-0e for guile-devel@gnu.org; Wed, 08 Feb 2012 17:10:53 -0500 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 010018830; Wed, 8 Feb 2012 17:10:52 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:date:message-id:mime-version:content-type; s=sasl; bh=N 9tyRVafVN8Z3hgNsW+KjUe4aN0=; b=xdPwhPbAVYaK2bpAsvNFkiCnnexXg6TMs XpDChL9gRHhyFCY4hE0D6CcdfgytY4pG++43MKo9JUtE20LB+9slgufZkmVZHsLv haUlCk1CcWIS5/jinPHbC6mI0yFokJrnD+j4cFFFQki+qDK5CGRmp24vXW8DCl/g sAoopjt1KA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:date:message-id:mime-version:content-type; q=dns; s= sasl; b=eNlB55D36MK9rooAqyFH+gsSZ/hRKGHRFSKuKf9xBT/9GYYUKZJ1lazq c+NGVkIRB7pEI6Z/yVTIY+rX0qle/3DxT+Qr/DxuDaWhCTVB9uURwBQrtMX89Jz8 oHAiHLRfThdnfhN3AH6Ph39ny0KvcvIOz4UVAH5GBhKcu+/uxdw= Original-Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id EC22A882F; Wed, 8 Feb 2012 17:10:51 -0500 (EST) Original-Received: from badger (unknown [90.164.198.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 1E409882E; Wed, 8 Feb 2012 17:10:50 -0500 (EST) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) X-Pobox-Relay-ID: C307CE3A-52A1-11E1-8EBA-65B1DE995924-02397024!a-pb-sasl-sd.pobox.com X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 74.115.168.62 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:13830 Archived-At: Hi, [Copying Bruno for an iconv question; see the end] I was testing out the threaded web server and it was working well. Then I tried it out with tekuti, a blog engine that uses git as the backend. It uses (ice-9 popen) to talk to the git binaries. It was deadlocking and segfaulting and all kinds of things! The reason is that when you fork(), only the thread that calls fork() survives into the child. If another thread was in a critical section -- i.e., held a mutex -- it just stops. The mutex remains taken, and nothing will ever unlock it. (Or is it in an undefined state? Standards lawyers are welcome to input here.) Of course whatever data structures the threads are working on are in whatever inconsistent state they were in as well. This is a problem for Guile, even in the (ice-9 popen) case in which we try to do the minimal amount of Schemely things before calling exec(). In particular there is the symbol table, which gets new things interned due to make-prompt-tag (clearly prompt tags should not be symbols), and there is the GC allocation lock, and there is the ports table, and the mutexes on the individual ports (in master). The solution is, besides just avoiding fork() and threads, to take locks on all interesting data structures when you fork(). Fortunately there are not too many, and most locks are not nested, so it seems to be a doable thing. In wip-threads-and-fork, I added a scm_c_atfork interface to define functions to call before and after a fork. It's like pthread_atfork, though without the separate functions for parent and child (is that needed?), and with the ability to have user data. Also the allocation lock is taken last. I also added some CLOEXEC-related hacks to that branch. We'll need a new gnulib for accept4. Finally, there was some mess with iconv(). iconv_open() is threadsafe, but on glibc it loads gconv modules, within a lock. It could be that another thread was in iconv_open (and holding the gconv lock) when the fork happens, preventing the child from doing scm_to_locale_string to produce the argv for the execlp. To fix this, I added locking around all iconv usage, including indirect usage via libunistring. This is pretty nasty. I guess the Right Thing would be a pthread_atfork() within gconv; Bruno, is that correct? I'm hesitant to do much threading-related work on stable-2.0, as master has a much better story there. Dunno. Anyway, thoughts welcome. With that patch series and wip-threaded-web-server, I am able to happily hammer a test tekuti instance without problems. I'll try it out in production shortly. Fingers crossed! Cheers, Andy -- http://wingolog.org/