Re: [cc65] signals

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.

> 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.

> 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.

> 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.

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.