Re: exemption-wait question

[<don...@is...>]

Vladimir Tzankov writes:
 > On 11/1/10, Don Cohen <don...@is...> wrote:
 > > > The only way to implement thread-interrupt while we are waiting in
 > > > pthread_cond_wait() is to signal the condition/exemption, run the
 > > > interrupt function and continue to wait. After we signal the exemption
 > > > - mutex is reacquired automatically by the OS. As final result - lock
 > > > is held when the interrupt functions is executed.
 > > Ok, so you can never look up the stack and find that you're in
 > > exemption-wait.  If you interrupt while in that function you find
 > > yourself ready to execute the thing after it.  And at that point
 > > exemption-wait has returned T.
 > 
 > Have you tried it? exemption-wait does not return when it handles
 > interrupts - interrupt function is called from it.
Then I misinterpreted your text above.
Let me try again.
Exemption-wait releases the lock and then calls pthread_cond_wait?
Or perhaps pthread_cond_wait releases the lock.
We then try to interrupt.
At that point pthread_cond_wait gets the lock (might have to wait for
it!) and exits but we're still in exemption-wait?  So then we call
the interrupt function, e.g., debugger.  And we see
- exemption-wait on the stack
- we have the lock
If I then do continue, the condition will be retested if :test was
supplied and that will probably go back to pthread_cond_wait.
If no test was supplied or if I return from exemption-wait then
if I have supplied my own loop, it will retest, call exemption-wait
again and that will call pthread_cond_wait again.
Otherwise (return from exemption-wait and no test or loop), it's as
if exemption-wait returned (whatever value I chose).
Is that all correct?

 > When you interrupt a thread and do not perform non-local exit from
 > interrupt function - the thread resumes normally. If you inspect the
 > stack from the interrupt - you will see all
 > mutex-lock/exemption-wait/read/etc there.
Ok, good.  What can I pass to thread-interrupt to just show the top
few functions on the stack and then resume?

 > Again - it seems you want to layer another scheduler on top of
 > primitives that clisp provides. Take a look at portable-threads
 > (http://gbbopen.org).
ok, thanks