From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 26 19:28:42 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 E898116A420; Thu, 26 Jan 2006 19:28:42 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E09B43D7D; Thu, 26 Jan 2006 19:28:22 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 26 Jan 2006 11:28:20 -0800 Message-ID: <43D922D5.1000307@elischer.org> Date: Thu, 26 Jan 2006 11:28:21 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jose Marcio Martins da Cruz References: <43D74F91.2090009@ensmp.fr> <43D7C786.1090803@elischer.org> <43D7E45E.8070103@ensmp.fr> <43D802DF.9040003@elischer.org> <43D88E69.1020102@ensmp.fr> In-Reply-To: <43D88E69.1020102@ensmp.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 19:28:43 -0000 Jose Marcio Martins da Cruz wrote: >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... > > > often what is done is to exec itself again with a different argument to make it know it is the child. why do you need to fork? why not just use more threads? >>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 ? > > I can suggest the threads programming book Programming with POSIX Threads by David R. Butenhof He was the main person behind the posix threads anyhow so he's pretty authoratative. >Thanks very much for all your very helpful hints. > >Jose-Marcio > >_______________________________________________ >freebsd-threads@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-threads >To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" > >