Quoting Stephan Uphoff <ups@stups.com>:
> YAMAMOTO Takashi wrote:
> > how about a user-kernel shared variable used to indicate if
> > any upcall handler is executing or not?
> > (iirc, freebsd kse does a similar thing)
> 
> This would work beautifully with the current implementation
> since it only supports a single virtual processor.

My first thought was to make the locks critical to the pthread library 
include an identifier to the ucontext which holds the lock and then 
register these locks with the kernel and have the switching code check if 
it's going to block an lwp which is holding such a critical lock.

I'm now thinking that a lock counter in ucontext_t might work.  It would 
count the number of critical locks held.

Stephan:  Would this be sufficient to limit disabling upcalls as suggested 
in your original note?  If I understood you correctly, upcalls would be 
disabled if a thread is preempted and the thread is in a critical section?

> -  upcalls will block trying to acquire pthread__runqueue_lock
>           and will not return upcall stacks to the kernel.

wouldn't it be possible to recycle stacks before we try to get any locks or 
at least recycle stacks if we detect that we are going to wait for a lock?  
Have you identified which locks beside the runqueue lock can lead to this 
problem?  Is holding locks the only porblem?

-- 
Christian Limpach <chris@pin.lu>