On May 22, 2007, at 6:02 PM, Nathan J. Williams wrote:

> Rhialto <rhialto@falu.nl> writes:
>
>> On Fri 18 May 2007 at 11:42:28 -0700, Bill Stouder-Studenmund wrote:
>>> On Fri, May 18, 2007 at 02:52:31PM +1000, Daniel Carosone wrote:
>>>>  If the upcall in question tells libpthread that the lwp has been
>>>>  blocked, the upcall stack doesn't get recycled to process more
>>>>  upcalls until the lwp later unblocks.
>>>
>>> I don't think that's fully correct.
>>>
>>> There are two different stacks involved. There's the stack of the  
>>> thread
>>> that was running, made a system call, and got blocked, and then  
>>> there's
>>> the stack for the upcall telling libpthread about the blockage.
>>
>> Why do these need to be different stacks? I would think that a  
>> blocked
>> stack would make a perfect candidate for temporary use for upcalls.
>>
>> I'm probably missing something here, because it seems too obvious :-)
>
> The SA/pthread library uses the stack as the thread ID, essentially,
> so things like locking wouldn't work properly, because the lock owner
> would be wrong.

Is there any reason why UNBLOCK upcalls couldn't be delivered on the
unblocking thread's stack?  It's there, it's available, and it's
not going to be used until that thread is unblocked.  and if it is
immediately unblocked, you're already there and running and can just
setcontext :)