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

"David Gravereaux" <davygrvy@pobox.com> wrote in message
news:hpu9r1td0sfau69li2g1086pu2ne99m4v7@4ax.com...
> On Fri, 30 Dec 2005 09:32:30 +0100, Uwe Klein
> <uwe_klein_habertwedt@t-online.de> wrote:
>
> >> 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.
> >
> >but where is the difference to things like fileevent?
>
> By taking the responsibility to install a handler, I should be certain
> that when I call Tcl_AsyncMark, the queued event will get serviced. If
> it doesn't get serviced, the blocking with Tcl_ConditionWait for the
> return value to exit the handler will block the OS supplied thread for
> infinity.
re an extension: TclX for windows already exists and is part
of AS distribution. Is that code at all close to what you're
contemplating? On the other hand I kind of agree with
Uwe Klien that tcl/tclsh already has event-driven features that
fail to work if the programer neglects to start the event loop. Of
course "fail to work" should not include disabling the whole program
as you seem to imply with "block the OS supplied thread for infinity"
For my druthers, it would be great to have the signal catch just
be native. Thanks for looking into this and Happy New Tcl Year!
>
> I could do a timeout I guess... Ok, this is probably workable but
> tclsh would require a threaded build or... I'll just use a native
> event object..
Received on Tue Jan 3 03:09:49 2006