Hi, "Julian Graham" <[EMAIL PROTECTED]> 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. _______________________________________________ Guile-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/guile-devel
