> > 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.
Having been an active developer/maintainer of Hugs for a number of
years and having dealt with most bug reports received during that
time, I stand by my claim.
Can you try my suggestion please?
> I suppose the problem lies in the interaction between "input.c" and
> "hugs.c".
Can you be more precise? What form of interaction do you mean?
> > 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.
The POSIX standard does not guarantee that it is safe.
AFAIK, Linux documentation does not say one way or the other.
My suggestion that it isn't safe on Linux is based on reading a
description of how Linux implements POSIX semantics - I spared you the
details of how it restores the old signal mask after signal handling
completes.
Can you point me to something that says it is safe?
> > 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.
Sorry, I should have said that I knew this didn't apply to Linux. I
suspect that it does apply to NT and it certainly applies to the
microkernel operating system I am working on.
> > 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.
That is true but POSIX disables the triggering signal during signal
handling to avoid a race condition where a second signal is received
after the signal handler has reinstalled itself but before the signal
handler has completed.
Quote from "man 2 sigaction" - the second sentence is the important
one:
sa_mask gives a mask of signals which should be blocked
during execution of the signal handler. In addition, the
signal which triggered the handler will be blocked, unless
the SA_NODEFER or SA_NOMASK flags are used.
What I was describing was the masking of signals that is done
automatically when entering a signal handler and undone when exiting.
If you never exit the handler (ie you longjmp out of the handler),
the signal will never be reenabled.
--
Alastair Reid [EMAIL PROTECTED] http://www2.cs.utah.edu/~reid/
