Re: [cc65] signals

Ullrich von Bassewitz wrote:

>Hi!
>
>On Thu, May 26, 2005 at 05:09:11PM +0100, dominic beesley wrote:
>  
>
>>Or do you mean the fact that another signal may be sent before the signal
>>handler has a chance to reinstall itself?
>>    
>>
>
>That is why I call them unreliable, and actually that's how they're called in
>the literature.
>
>  
>
Fair enough, but I think for the BBC trapping one or more and buffering 
as one or
maybe two should work well enough.

>>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:
>>    
>>
>
>That's as I feared. You cannot call library code from this interrupt handler
>without the risk of data loss or crashes. For example, the file I/O routines
>may have been in the middle of updating some global data when the interrupt
>occurs. If you call the file close routines in this state, very bad things may
>happen. The same is true for other global data in the library.
>
>As I wrote in my last mail, I had a discussion with Oliver about using signals
>for a similar purpose on the Aple ][, but the result was that there is no easy
>solution.
>                               
>This means that you cannot use signals for your escape handling. Solving the
>associated problems is not possible without increasing the code size and speed
>penalty of the library code.
>
>  
>
Well, some kind of user intervention is relevant. The only other way is 
to poll every time
an OS function is called, which could be a long wait in a big heavy 
loop. (Though most
people would get bored and press the BREAK key to reset anyway I suppose)

The way all the OS I/O functions work on the BBC means that I have to 
hang off an
interrupt vector to find out whether they failed anyway. However this is 
helped by the
fact that I _know_ that I'm in an OS function and can set up an 
appropriate situation
(something a bit like setjmp/longjump).

After some more testing, and lots of reading through the OS disassembly, 
it seems
though that hanging off the Escape vector is not too bad. Do the Unices 
not have these
problems though. Processes can be swapped out at any point and then 
signals delivered?

>>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.
>>    
>>
>
>I don't know a way to do that.
>
>  
>
Ok. I was hoping there might be a way to define a symbol (other than 
__BBC__ or
whatever) without doing lots of ifs and elses. If a table based 
implementation was put
in place, I wouldn't want to go taking up space on other platforms.

>>so that I can have extra signals for BBC by #defining _SIG_MAX or
>>something before
>>signal.c is made?
>>    
>>
>
>There is no _SIG_MAX and there is no signal.c in 2.10.1 or the development
>version. If you need something like _SIG_MAX it would be possible to add
>something like that to signal.h. But because of the reasons explained above, I
>doubt that a working implementation is possible anyway.
>  
>
There are other signals which might come from the calling of an OS 
function. The OS
functions will be called in a _known_ state so that handling of these 
functions can be
handled in a more reasonable way. However some of the returns are not 
covered by
the handful of signals present in signal.s, or the C standard.

>Regards
>
>
>        Uz
>
>
>  
>
Cheers

Dom

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