Daemon News Ezine BSD News BSD Mall BSD Support Forum BSD Advocacy BSD Updates

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Changes from 5.2.1 to 5.3 (theads / signal handling)

Jose Marcio Martins da Cruz wrote:


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
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 ?

I can suggest the threads programming book
Programming with POSIX Threads
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.


freebsd-threads@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-threads-unsubscribe@xxxxxxxxxxx"