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 21636BB9C for ; Tue, 22 Nov 2005 21:57:28 +0100 (CET) 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 jAMKvRja023149 for ; Tue, 22 Nov 2005 21:57:27 +0100 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 VAA22020 for ; Tue, 22 Nov 2005 21:57:27 +0100 (MET) Received: from einhorn.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id jAMKvQ5s019181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 22 Nov 2005 21:57:26 +0100 X-Envelope-From: oliver@first.in-berlin.de X-Envelope-To: Received: from first.in-berlin.de (e178003105.adsl.alicedsl.de [85.178.3.105]) (authenticated bits=0) by einhorn.in-berlin.de (8.12.10/8.12.10/Debian-4) with ESMTP id jAMKvO8q025831 for ; Tue, 22 Nov 2005 21:57:25 +0100 Received: by first.in-berlin.de (Postfix, from userid 501) id C13C21A585D; Tue, 22 Nov 2005 21:56:46 +0100 (CET) Date: Tue, 22 Nov 2005 21:56:46 +0100 From: Oliver Bandel To: caml-list@inria.fr Subject: Re: [Caml-list] Threads & Fork Message-ID: <20051122205646.GB594@first.in-berlin.de> References: <1132673981.13170.17.camel@starlight> <87wtj07kv8.fsf@mid.deneb.enyo.de> <20051122155002.GB16451@first.in-berlin.de> <200511221832.55487.A.S.Usov@kvi.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200511221832.55487.A.S.Usov@kvi.nl> User-Agent: Mutt/1.5.6i X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 X-Miltered: at nez-perce with ID 43838637.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 43838636.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; oliver:01 bandel:01 oliver:01 in-berlin:01 caml-list:01 threads:01 bandel:01 threads:01 ocaml:01 run-time:01 posix:01 posix:01 api:01 unix-module:01 threading:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.3 On Tue, Nov 22, 2005 at 06:32:55PM +0100, Alexander S. Usov wrote: > On Tuesday 22 November 2005 16:50, Oliver Bandel wrote: > > On Tue, Nov 22, 2005 at 04:39:07PM +0100, Florian Weimer wrote: > > > * Jonathan Bryant: > > > > I'm confused as to why the attached code hangs. My understanding of > > > > Unix.fork () is that it completely clones the current process, which in > > > > my understanding, clones the processes's threads as well. Apparently, > > > > though, that is not the case, because I can't join the thread in both > > > > the parent and the child. > > > > > > I can't speak for the OCaml run-time, but POSIX fork only duplicates > > > the current thread, so the new process is essentially single-threaded. > > > > I doubt that this is true. > > Unix-fork() copies a complete process. > > If the original has threads, the copy also have. > > I don't think that POSIX handles this different to old Unix API. > > > > Unix-module should do the same as the C-call of fork(2). > > > > Threads are running inside a process, like any other > > function. So all should be copied completely. > > > > But using POSIX-threads and Unix-API can yield to many problems, > > for example POSIX threading signals and Unix-signals are clashing > > together and the behaviour can be undefined... > > [Option End]A process shall be created with a single thread. If a > multi-threaded process calls fork(), the new process shall contain a replica > of the calling thread and its entire address space, possibly including the > states of mutexes and other resources. Consequently, to avoid errors, the > child process may only execute async-signal-safe operations until such time > as one of the exec functions is called. [THR] [Option Start] Fork handlers > may be established by means of the pthread_atfork() function in order to > maintain application invariants across fork() calls. [Option End] > > (c) SUS v3 OK, I looked into my literature... "Pthreads specifies that only the thread calling fork exists in the child." (David R. Butenhof: Programming with POSIX-Threads, p. 197) OK, so I was wrong with my doubting... ;-) But... the other threads' states in the child are the same as in the parent.... and other things are also very.... strange. Mutexes and other things are living inb the child, but threads that possibly would work with them don't exist... ...there is no cleanup done... ...well.. so better don't use it this way. So Butenhof said the same as you found in SUS v3 .... Ciao, Oliver