[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netbsd-tech-kern
Subject:    sys_sa_preempt()
From:       Bill Stouder-Studenmund <wrstuden () NetBSD ! org>
Date:       2007-05-23 1:31:53
Message-ID: 20070523013153.GB24717 () netbsd ! org
[Download RAW message or body]


One obvious thing (Xtos and others have pointed it out) we need to add to 
SA is some way to kick a running thread in the head, so to speak. We need 
to be able to send signals to running threads. With concurrency > 1, it 
could really be running on another CPU.

My thought was to actually implement sa_preempt(2) and have it deliver an 
SA_UPCALL_USER upcall. Then let libpthread's upcall handling do whatever 
needs doing. That way if you need to do something in the thread's context 
that shouldn't destroy the thread, you actually have a chance of doing it. 
:-)

Most everything is easy. I just have libpthread track which lwp a given 
thread is running on (we already track virtual cpu), and then pass that 
into sa_preempt(2).

The problem I'm emailing about now is how exactly should sys_sa_preempt(), 
which actully implements this, work?

Finding the targeted lwp is easy. Building an upcall event is easy.

Even kicking the other CPU in the head isn't hard, we just need a way to 
fire off an IPI to it. As I understand it, the interrupt handler will 
deliver the upcall on its way back to userland.

My question is about the upcall itself.

I'm confused about how exactly I'm supposed to set the "event" and 
"interrupted" lwps.

In the simple case where thread X is running on lwp Y and I send in the 
upcall and it gets delivered when Y was running, I think I want both the 
"event" and "interrupted" lwps to be the same. We still have to do the 
"You got interrupted who knows when" dance on lwp Y (thread X). But we 
also want to process signals on the thread on lwp Y (thread X), so it 
really needs to be the event.

We however have an assert in our kernel upcall enqueue code to say that we 
can't send an upcall where both are the same. Why? Will libpthread 
explode?



A second issue is that I need some way to tell the upcall delivery code 
that the "interrupted" thread is whatever is running. A flag that 
sa_makeupcals notices seems like just the trick.



The astute observer will note that I'm talking about whacking an lwp on 
the head when I really want to whack a given thread on the head. With 
concurrency > 1, it is possible that thread X blocks and instead thread Z 
is running on lwp Y by the time the upcall actually gets into userland. I 
think the right way to handle this is for a hook in libpthread to notice a 
defered signal is waiting when it's about to take thread X off of the CPU 
and to instead perform the signal handling right as it starts thread Z. 
But this is totally a userland issue.

Take care,

Bill

[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]