libthread_xu pthread_exit() behaviour

Simon 'corecode' Schubert corecode at fs.ei.tum.de
Thu Sep 22 10:11:14 PDT 2005


Hey,

at the moment I'm looking at the threading stuff and I found some 
issues:

1.
If the main() thread pthread_exit()s, the "process" visible to the 
parent will exit.  This is because the kernel doesn't have the notion 
of "threads" and "processes":  The pid of the "process" goes away and 
thus all other threads become background processes (threads).

I am not sure where this is handled best.  Maybe in kernel when dealing 
with p->p_peers (see next point):

2.
If the main() thread exit()s, it won't tear down all other threads.  
This is an easy fix:  just use RFTHREAD in the rfork_thread() and this 
works as expected.  On the other hand if the main thread 
pthread_exit()s (see above) it will kill all other threads as well.

If we want the kernel to keep thread leaders around (sleeping?) until 
all peers have been pthread_exit()ed, we need a way for the userland to 
signal to the kernel that the thread is actually pthread_exit()ing and 
not trying to tear down all threads with exit() [new syscall?]

Am I missing something?  Comments welcome!

cheers
  simon
--
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low $$$ NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \
Attachment:
PGP.sig
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00020.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: This is a digitally signed message part"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20050922/3e96cde9/attachment-0013.obj>


More information about the Kernel mailing list