Changes from 5.2.1 to 5.3 (theads / signal handling)

[Jose Marcio Martins da Cruz]

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