Messages in this thread |  | | Subject | Re: proc fs and shared pids | From | <> | Date | Mon, 5 Aug 1996 22:43:52 -0400 (EDT) |
| |
I'm replying to two messages here, sorry. :(
> The only thing is that this makes signal handling bizarre. > Suppose I have one thread that waits for a SIGHUP and controls the > shutdown. How do I get the rest of the world (consider 'init' for > example) to send the SIGHUP to the correct thread?
If we are talking POSIXish behavior then the job of catching SIGHUP is yours. If a number of threads are eligible, then which thread gets the signal is specified as implementation dependant. Since pthreads have thread specific signal masks, this isn't a problem. If it is, threads may not be appropriate in that particular case.
> How will getppid work under this scheme? What will happen if the
It should return the parent of the PROCESS in my opinion, not the thread.
> thread that created a particular thread dies? Do you send a SIGCHILD? Who > reaps threads return values?
How is the thread exiting? The thread way by pthread_exit() or by the real exit()? You use pthread_join() and pthread_detach() to reap the thread, not wait().
> > Allowing user mode threads to share pids is probably a mistake. For the > > purpose of process control, it probably makes more sense to regard them as > > special cases of processes, i.e., processes with shared memory.
How else do you get user mode threads? The fact that a thread is a user level one implies that it shares process resources and is invisible to the kernel. At least in a general sense. Maybe you meant LWP?
Melvin
|  |