"Charles M. Hannum" <abuse@spamalicious.com> writes:

> If I understand this correctly, the user-level library creates a bunch of 
> special-purpose threads for handling upcalls.  When an upcall happens, a 
> thread is allocated (by using copyin() to inspect each one until we find an 
> empty one!)

I can't say I'm thrilled with the set of changes that introduced that
mechanism in sa_getstack().

> and the current processor state is saved there.  The user-level 
> upcall handler is poked into the PC, and we return.

The current processor state is saved on the stack of the LWP where the
event happened, below the current stack pointer. The upcall's stack is
only used for passing arguments to the upcall routine, including
pointers to that state on other stacks.

> The upcall stack/thread gets cleaned up later when the LWP is unblocked, in 
> response to another upcall.  This is where the fun begins.

The upcall stack/thread is cleaned up when the upcall handling
SA_UPCALL_BLOCKED finishes, which is generally long before the LWP
unblocks.

It's still true that running out of upcall stacks is bad news.

        - Nathan