Re: [cc65] signals

Hi!

On Wed, May 25, 2005 at 05:36:40PM +0100, dominic beesley wrote:
> When SIG_IGN is set as a handler, to ignore signals, should
> this not be sticky? i.e. the signal ignored completely. The
> implementation in 2.10.1 resets it...

That is the old signal handler problme: cc65 implements unreliable signals,
because this was a lot easier to do. The standard allows this explicitly.

> I've had to change signal.h to declare _sig_ign and _sig_dfl
> as __fastcall__ is that correct.

You're right, that is an error in the header file. I will fix it.

> I want to override _sig_dfl for BBC micro so that it traps
> SIGINT and aborts to the OS when Escape is pressed and not
> captured. What is the best way of doing this? I don't want to move
> it from common otherwise it'll need redefining for all the other
> architectures...

I had a discussion with Oliver regarding this topic, and we came to the
conclusion that - at least for the Apple - it is almost impossible to map an
asynchronous signal to a signal handler, and terminate the program in this
case. If the Escape key generates something like an interrupt, you don't know,
which part of the code has been interrupted. Hard aborting the program is
possible, but even this may leave the operating system in an unstable state.
Executing more cc65 code (like flushing disk buffers) is not possible, because
disk routines may have been interrupted, and most of the code is not
reentrant.

Moving sigtable.s and the _sig_ign and _sig_dfl functions to the platform
specific code is possible, but I would suggest to check first if it is really
possible to catch asynchronous signals. Another way would be to have a table
with default actions exported by the platform specific code, so _sig_dfl is no
longer a function, but will fetch a vector from a table. This would make it
platform specific, and signal specific (default actions can differ for the
signals).

The current signal stuff was just a first implementation done by me, to make
cc65 more standards compliant. As far as I know, no one did really use it
until now, so it is clear that some problems pop up once people start using
it:-)

Regards


        Uz


-- 
Ullrich von Bassewitz                                  uz@musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.