[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: thread cancellation, take 2

From: Ludovic Courtès
Subject: Re: thread cancellation, take 2
Date: Thu, 20 Sep 2007 17:18:51 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)


"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

>   (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,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]