Changes from 5.2.1 to 5.3 (theads / signal handling)
Jose Marcio Martins da Cruz
Jose-Marcio.Martins at ensmp.fr
Thu Jan 26 00:55:08 PST 2006
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
> 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
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.
More information about the freebsd-threads