Re: LWPs (was:Re: proc fs and shared pids)

Mark.Hemment@uniplex.co.uk
Fri, 2 Aug 96 09:28:34 +0100

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).

>Lex

markhe