From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 5B3DEBB83 for ; Tue, 23 May 2006 05:04:06 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k4N345tK024969 for ; Tue, 23 May 2006 05:04:05 +0200 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id FAA25803 for ; Tue, 23 May 2006 05:04:05 +0200 (MET DST) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k4N343Up026651 for ; Tue, 23 May 2006 05:04:04 +0200 Received: from rosella (ppp28-237.lns1.syd6.internode.on.net [59.167.28.237]) by smtp1.adl2.internode.on.net (8.13.6/8.13.5) with ESMTP id k4N33q59059173; Tue, 23 May 2006 12:33:53 +0930 (CST) (envelope-from skaller@users.sourceforge.net) Subject: Re: [Caml-list] Freezing From: skaller To: david.baelde@ens-lyon.org Cc: Ocaml In-Reply-To: <53c655920605221704r5ff97fdfj1fa953f6f858a8b1@mail.gmail.com> References: <53c655920605221704r5ff97fdfj1fa953f6f858a8b1@mail.gmail.com> Content-Type: text/plain Date: Tue, 23 May 2006 13:03:51 +1000 Message-Id: <1148353431.19894.19.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 44727BA5.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 44727BA3.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; unix:01 unix:01 waitpid:01 threads:01 buffer:01 pointers:01 buffer:01 pointers:01 threads:01 2006:98 wrote:01 sourceforge:01 caml-list:01 terminate:01 hangs:02 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 On Tue, 2006-05-23 at 02:04 +0200, David Baelde wrote: > <<< > flush_all () ; > let pid = Unix.fork () in > if pid = 0 then begin > ignore (Unix.alarm 20) ; > Fetch.cp there here ; > exit 0 > end else > Unix.waitpid [] pid > >>> > The main process is threaded but the child isn't. Isn't it weird that > it gets blocked in such a way ? When you fork() a process the whole memory space of the parent is cloned, including locks, file handles, buffers, etc -- including those being used by threads other than the one doing the fork(). So now you can have this: some thread of the parent is doing I/O and acquires a lock, you fork, then the buffer is written, pointers into it adjusted, and the lock is released. When the forked() process tries to terminate .. the lock is locked because it is a copy of the original lock. And the buffer pointers say the buffer is full. So the process hangs waiting for the lock to be released and the buffer to be emptied by a thread that has already done so .. but the state saying that is in the original address space, not that of the process. The moral is -- use threads or processes but not both together, Unix can't handle it. -- John Skaller Felix, successor to C++: http://felix.sf.net