Re: LWPs (was:Re: proc fs and shared pids)
Lex Spoon (sspoon@clemson.edu)
Fri, 2 Aug 1996 18:41:33 -0400 (EDT)
Mark.Hemment@uniplex.co.uk wrote:
>
> Lex wrote:
> >Mark.Hemment@uniplex.co.uk wrote:
> >> clone() tries to give Linux LWPs. Basically, this involves
> >> allocating and setting up a _new_ task struct, and referencing some
> >> other structures (signal handlers, etc) from the clone()ing process. I
> >> would say this is the _wrong_ way round.
> >>
> >> The new thread should use the _old_ task struct, and allocate memory
> >> for the state which it does not want to share with the cloning process.
> >> This could be achieved with a new structure 'thread struct', which
> >> contains the thread's state. An incomplete list of what would be in the
> >> thread struct;
>
> > Let me give an example for my case. Suppose I want to write an X program
> > which does some lengthy computation, and I decide to have one thread
> > do the calculation while a second thread draws intermediate results in
> > a window. Here are two options I have under Linux 2.0:
> > 1) Use clone() to create the threads, and communicate via
> > shared memory.
> > 2) Use fork() to create the "threads", and communicate via
> > pipes.
> >
> > From the kernel's perspective these two have some significant
> > differences, but from the perspective of userspace each just looks a
> > pair of cooperating processes. In neither case would you want to throw
> > a signal to just one of the two "threads"; you should send it to both
> > of them and let them divvie it up however seems reasonable.
>
> As I suggested (and was snipped out), each thread has its own signal
> mask, with 'interrupt' (ie. not exception) signals delievered to the
> thread which is not blocking the signal (perhaps it makes more sense
> to have an ignore mask). If more than one thread allows delievery
> of a signal, it is non-deterministic on which one gets it.
>
> In your example, after creating a new thread to draw the results, it
> would set its signal mask (as would the orignal thread) to tell the
> OS what signals it wants to handler. Perhaps your computational thread
> wants SIGUSR1, while your drawing thread wants to know nothing about
> it - they would use the mask.
>
> Perhaps, some of your drawing can be performed in parallel, and
> your library is intelligent enough to monitor the system load. When it
> notices the load is low, it starts up another thread to help (OK, not
> a perfect example). Would another process (which wants to communicate
> with your process), really want to care how may threads are drawing?
> If the same pid is used for all threads, then it doesn't need to know.
> When one of the threads handles the signal, it decides if it should
> be 'passed-on' to any other threads in the process (delivering the same
> signal to all threads could create nasty race conditions in the
> users application).
>
Normal Unix processes can use signal masks, too, achieving the same
effect. You just have to remember to send the signal to the process
group instead of to an individual process. Furthermore, it is easy
to signal just specific "threads" of a process group; to do that with
a group-of-threads-process, you have to define a new interface.
lex