Re: [cc65] signals

Ullrich von Bassewitz wrote:

>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.
>
>  
>
When you say "unreliable", do you mean the fact that it may be interrupted
whilst reseting the vector? I'm guessing this should be relatively easy to
solve?

Or do you mean the fact that another signal may be sent before the signal
handler has a chance to reinstall itself? In that case I'll stick with 
unreliable signals
for now (to get things working) and then have to look at "blocking" 
recurrent
signals until after the signal handler returns (which could get messy!)

[snip]

>>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.
>  
>
After sitting up all night last night I've got it working, though I've 
not thoroughly tested it.
I've at least got it to close all open files on the way out (which was 
better than before,
pressing escape would just drop back into the BASIC ROM and leave all 
the files open!)

The ESCape key calls an event vector (kind of like an interrupt vector 
but after some
processing by the OS, like keyboard scan etc). I hook the event vector 
and if it gets
hit call the escape handler:

1. pushes flags and processor registers
2. pushes the zero page area to the parameter stack (sp)
3. calls the installed SIG_INT handler
4. pops the zero page area from the parameter stack
5. pops flags and registers

the SIG_DFL handler for SIG_INT just does a BRK instruction to halt back 
to the
OS (plus it has to reenable keyboard interrupts! I'm currently reading 
through the
BBC OS disassembly to see what I should really do about this).

>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).
>  
>
If its ok I'll look at doing this as some kind of table.

In doing this is there some way of automagically including the _right_ 
platform specific
header file with out lots of #if/else's i.e.

#include "__platformspecific.h__"

so that I can have extra signals for BBC by #defining _SIG_MAX or 
something before
signal.c is made?

>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
>
>
>  
>
Thanks once again for a considered reply.

Dom

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