[PATCH] 1:1 Userland threading stage 2.11/4:

[Simon 'corecode' Schubert]

Matthew Dillon wrote:
:Matthew Dillon wrote:
:>     Just as an aside, I seem to remember POSIX making a distinction between
:>     'global' signals and 'per-thread' signals.  Something about a signal that
:>     cannot be handled by a thread is queued globally and then processed by
:>     the first thread that can take it, or something like that.
:
:The current code unconditionally (tries to) queue to the first lwp; the 
:next step will queue it on the first lwp that doesn't mask the signal, 
:and failing that, globally. Though again, that's a next-step :).
:
:>     This would imply that we need to have a two-level signal delivery 
:>     architecture (lwp layer and process layer).
:
:I guess so too. Simon already has some thoughts about is, we talked this 
:afternoon (while I was reviewing the patch).
:
:Cheers,
:-- 
:         Thomas E. Spanjaard
:         tgen at netphreax.net

    I think we want to avoid having to scan the LWP list for a process.
    It is almost certainly easier for the LWP itself to simply check both
    signal sets (the per-LWP set and the per-process set).  We are only
    talking about a few instructions here... maybe a few nanoseconds in
    time.
hm.  first I thought that the kernel will upcall into userland as soon as there is a signal, but it seems that only happens on task switches?

another thing is that if all LWPs are sleeping in the kernel and some of these sleeps are interruptible, one of these LWPs has to receive the signal by interrupting the sleep.  so in any case we will have to run down the list.  on the other hand, signals don't happen that often.

with this patch the LWPs will already check both signal sets.

cheers
 simon
--
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low €€€ NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00006.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20070204/b95ed636/attachment-0020.obj>