From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 26 08:55:07 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE43A16A420; Thu, 26 Jan 2006 08:55:07 +0000 (GMT) (envelope-from Jose-Marcio.Martins@ensmp.fr) Received: from saci.ensmp.fr (saci.ensmp.fr [194.214.158.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87DBD43D45; Thu, 26 Jan 2006 08:55:07 +0000 (GMT) (envelope-from Jose-Marcio.Martins@ensmp.fr) Received: from [127.0.0.1] (localhost.ensmp.fr. [127.0.0.1]) by saci.ensmp.fr (sendmail X.1.0.PreAlpha0.0) with ESMTP id S00000000000002D100; Thu, 26 Jan 2006 09:55:05 +0100 Message-ID: <43D88E69.1020102@ensmp.fr> Date: Thu, 26 Jan 2006 09:55:05 +0100 From: Jose Marcio Martins da Cruz User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20041221 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <43D74F91.2090009@ensmp.fr> <43D7C786.1090803@elischer.org> <43D7E45E.8070103@ensmp.fr> <43D802DF.9040003@elischer.org> In-Reply-To: <43D802DF.9040003@elischer.org> X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-threads@freebsd.org Subject: Re: Changes from 5.2.1 to 5.3 (theads / signal handling) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 08:55:08 -0000 Hello, Julian Elischer wrote: > Jose Marcio Martins da Cruz wrote: >>> also, does the child do an exec() after forking? >> >> No. The child gets out the father loop and calls another >> initialisation function. > > The Posix spec says that after a fork(0 teh child must do almost nothing > before calling exec() > and that AT A MAXIMUM it should only call async-safe functions. (i.e. > functions that can be called from > within signal handlers). So, if I understood, the better I can do is, instead of letting the child follow a different path after the fork, he shall better do an exec of another thing and start a clean process... > > There is all sorts of state being kept for the "now non existant" > threads in that address space. > > For example, some of them will still exist if they were stopped in user > space at the time, > but some of them will not (if tehy were in the kenrel at teh time). In > addition, > the process will now be marked "non threaded" in the kernel, as it now only > has one kernel thread (as specified by posix) so an attempt to schedule > another thread > from user space will lead to unknown behaviour. The child will most likely > run for a bit and then freeze up or die in some mysterious way. ( sound > familiar?). Very clear... Even on releases older than 5.3... 8-( You clarified a bug which was "harassing" me for a very long time... Can you point me a good doc about threads, signals, and such kind of things in FreeBSD context ? Thanks very much for all your very helpful hints. Jose-Marcio