On Mon, 1 Feb 1999, Alastair Reid wrote:
> I believe the problem is that Hugs relies on a property of signal
> handling that is not required by POSIX or ANSI C and does not hold on
> some platforms.
I don't think so. I suppose the problem lies in the interaction
between "input.c" and "hugs.c".
> Windows {3.1,95,NT} are three such platforms and
> Linux is perhaps another. The question is:
>
> Is it safe to longjmp out of a signal handler?
Under Linux, it is. But it is quite difficult to ensure that global
state is consistent after interrupting at an arbitrary point of
execution.
> On some platforms, it is not safe because signal handlers are run in a
> separate thread from normal evaluation. Longjmping from one thread's
> stack to another is dubious at best.
Under Linux, signals do not use separate threads. They use the normal
stack.
> On POSIX platforms, it is dubious because POSIX requires some signals
> to be disabled while handling a signal and reenabled when the signal
> handler returns. If the handler never returns, it's not clear when
> the signal can be reenabled.
By default, signals are one-shot. After a signal has been delivered,
signal() must be called again.
> Oh yes, one other related fact: I have a vague memory that the GNU
> readline library doesn't handle interrupts too well (or it doesn't
> like the way we react).
I do not use readline.
> ps Julian: this shouldn't be a problem for the Hugs-STG system since it
> does not longjmp out of signal handlers during Haskell evaluation or
> (I think) out of Haskell compilation.
This seems to be a good idea, since global state after doing
a longjmp out of some library function might be somewhat undefined ;-)
Best regards
Friedhelm
