Go to the first, previous, next, last section, table of contents.


why unreliable signals?

Why should the basic Muq signal system be unreliable? Shouldn't it promise reliable signal delivery at least within a given server, when no network packet loss problems are involved? Shouldn't the server at the very least guarantee that a division-by-zero signal within a job always gets reliably delivered?

Perhaps it should! But there are reasonable arguments against this:

It may be worth clarifying what we mean by signals being "unreliable" within a given server: We mean that there is no guarantee that a given signal sent to a given job will have any effect on that job, because if the only appropriate signal handler is already running, the new signal will simply be silently discarded.

To take the division-by-zero example, this means that a division-by-zero notification will be lost only if the division-by-zero happens in the division-by-zero handler. But isn't this what one wants, really? If the division-by-zero handler is generating division-by-zero events, re-invoking it will probably simply lead to an infinite recursion followed by a stack overflow, which doesn't seem an improvement. Under the Muq unreliable signal system, any division-by-zero exceptions raised within the division-by-zero handler will be handled by any prior division-by-handler if present, else by any more general error handler if present, else simply ignored. I think this is just about right.

For special cases where the signal absolutely -must- go through, but regular message streams are for some reason insufficient, one can build a more sophisticated mechanism on top of the basic Muq server facility, perhaps using some combination of both message streams and signals, or perhaps waiting for an acknowledging signal and resending after some timeout, or such. It will probably be a fairly complex system by the time it is complete -- likely too complex to make in-server implementation of it sensible or effective. The particular algorithm chosen may well prove to be application-dependent, which provides yet another reason to keep it out of the Muq server proper, which is intended to provide "mechanism, not policy" (to quote an X window system catchphrase).


Go to the first, previous, next, last section, table of contents.