The most frequent request is to move the [TclX] signal handling commands into Tcl. This page is to formalise that desire, leading to a [TIP]. There is some discussion/question as to the wisdom of doing this in [TclX Future].
The [TclX] commands falling into this category are:
: [alarm] <
> [signal] <
> [kill] <
> [wait] <
> [sleep]
Of closely-related interest:
: [execl] <
> [fork]
----
[LV] Why is execl and fork in this list? They really are not related
to signaling - more to posix.
----
It should also be pointed out that signals are actually talked about in the C standard, so really they are not strictly bound to POSIX. --[Setok]
----
Note that there is a ''large'' limitation with `Tcl_AsyncMark` on UNIX where the notifier will not wake if idle due to a brain-dead implementation of `Tcl_AlertNotifier`. See [http://sourceforge.net/tracker/index.php?func=detail&aid=502022&group_id=10894&atid=110894] or [http://sourceforge.net/tracker/index.php?func=detail&aid=502193&group_id=10894&atid=110894]. Once this is resolved, signals should work well. -- [DG]
----
[DKF]: Alas, [fork] doesn't work with [Thread]s due to issues with the pthread library. (The one I can remember is that locks are in an unknown state in the child process.) We should consider whether we should produce an equivalent of [tclsvc] for Unix that does a full disconnect (double-fork() and all) before processing any Tcl scripts so that the second-most important aspect is handled (the standard [exec] command is the most important one and isn't affected by the POSIX thread issues because it avoids the nasty parts).
<> Suggestions | TclX