Re: thread cancellation, take 2

[Ludovic Courtès]

Hi,

"Julian Graham" <address@hidden> writes:

> So: Is there a way to safely evaluate SCMs from C after a JMP into a
> weird context?  (I imagine the on_thread_exit code is called in a
> similar state, but it only superficially manipulates SCM values...)

Would it be possible to defer execution of the Scheme code (cleanup
handlers) to after the C cleanup handler has been called?

I.e., the C handler would push the Scheme handlers to a list that would
be eventually executed, when Guile is back into a "clean", regular
state.

>   (At the time I asked about this originally, Marius Vollmer suggested
> that cancellation be implemented as a system-async -- I think that
> approach leaves us with the same issues regarding the GC / stack,
> especially now that Guile threads are isomorphic to pthreads.)

Indeed, some form of deferred execution appears to be needed here, so
that Scheme code is not evaluated right from the C cleanup handler.

Now, if system asyncs can do the job, then it's better to use them
rather than some ad hoc mechanism as I suggested above.

>   On a related note, do you guys have any preferences as to the
> behavior of cancel-thread?  The way I've got it now, joining threads
> will receive the value of the final expression in the cleanup-handler
> list as the "result" of the canceled thread.  Does that make sense?

Sounds good.

> Also, should the items in the cleanup-handlers list be S-exprs or
> should I limit them to being thunks (kind of leaning toward the latter
> right now...)?

I'd prefer thunks as well, it looks more Schemey.

Hope this helps,
Ludovic.