This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug nptl/9804] pthread_exit from main thread: poor semantics, potential tty session lockup.


------- Additional Comments From kkylheku at gmail dot com  2009-01-31 07:43 -------
I have a better understanding what is going on in the kernel. The main thread 
has terminated.  The Ctrl-Z sends a SIGTSTP to the remaining threads in the 
normal way. The threads are suspended. Only, the defunct main thread is not 
available for handling the state transition properly. The expected behavior is 
that a status change occurs in the process that is detected by the shell which 
can then report that the job is in the background. This does not happen for 
the defunct process.

I don't think there is an easy way to fix this. The exit handling has to be 
changed in the kernel. If a thread which behaves like a main thread is 
terminating, it cannot simply run through do_exit and become a zombie. It 
should enter into some kind of wait function in the kernel to join the others. 
While in that function, it should be a regular sleep in which it can handle 
job-control-related signals.

A workaround could be hacked in glibc's __libc_start_main; a kind of 
synchronization on the termination of the other threads. The actual call to 
__exit_thread could be delayed until the other threads are known to have 
terminated (all the way to the kernel; I see there is a notification mechanism 
for a tid being cleared, and it acts as a futex too).







-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=9804

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]