Re: TclX on Windows - anybody successfully trap SIGTERM / SIGKILL

On Fri, 30 Dec 2005 22:49:24 GMT, "Donal K. Fellows"
<donal.k.fellows@manchester.ac.uk> wrote:

>David Gravereaux wrote:
>> I was thinking about this some more and I don't think this signal
>> stuff should be in tclsh at all.
>>
>> It should be in an extension or something.
>>
>> Here's why I think this.. To properly "trap" a signal I need to
>> assume the event loop is running. I think that's a bad asumption to
>> make for everyone by placing this code in the shell itself.
>
>Why are you thinking in terms of something so elaborate? The async stuff
>(Tcl_AsyncCreate/Tcl_AsyncMark) is designed specifically for handling
>interrupts, and the interpreter always services the async stuff (using
>Tcl_AsyncReady) when it is in a reentrant state. Fiddling around with
>lots of thread stuff is just a way to get confused. (The async API is
>how the TclX and Expect extensions handle signals on UNIX.)
>
>Of course, the async handler you set up with Tcl_AsyncCreate could just
>post an event to the event queue. That'd work just fine. But that's a
>higher-level operation, and could be written in Tcl because you've got a
>reentrant interpreter by the time it runs...
>
>Donal.

TclX and Expect don't do it right. It isn't safe to eval scripts
within the context of a Tcl_AsyncProc. Try it.. use a dual CPU
machine, some deep Itcl scopes and hammer Tcl_AsyncMark and watch Tcl
crash in random spots. From the Tcl_AsyncProc, Tcl_QueueEvent, then
eval in the Tcl_EventProc and all is safe.

That and I have to use the script result to determine the proper
return value from the handlerroutine which means block until the
script runs.
Received on Tue Jan 3 03:09:55 2006