lkml.org 
[lkml]   [1996]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: proc fs and shared pids
From
Date
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


\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.106 / U:1.376 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site