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


    \
     
     \ /
      Last update: 2005-03-22 13:37    [W:0.024 / U:31.348 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site