Date: Thu, 26 Jan 2006 11:28:21 -0800 From: Julian Elischer <julian@elischer.org> To: Jose Marcio Martins da Cruz <Jose-Marcio.Martins@ensmp.fr> Cc: freebsd-hackers@freebsd.org, freebsd-threads@freebsd.org Subject: Re: Changes from 5.2.1 to 5.3 (theads / signal handling) Message-ID: <43D922D5.1000307@elischer.org> In-Reply-To: <43D88E69.1020102@ensmp.fr> References: <43D74F91.2090009@ensmp.fr> <43D7C786.1090803@elischer.org> <43D7E45E.8070103@ensmp.fr> <43D802DF.9040003@elischer.org> <43D88E69.1020102@ensmp.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <http://btobsearch.barnesandnoble.com/booksearch/results.asp?userid=tj0j4oSCKr&btob=Y&ath=David+R%2E+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" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43D922D5.1000307>