Re: [cc65] Re: signals

Jonathan Graham Harston wrote:

>>Message-ID: <429C4ADE.6080801@brahms.demon.co.uk>
>>    
>>
> 
>dominic beesley <dominic@brahms.demon.co.uk> wrote:
>  
>
>>What if the user presses break, what if I _dont_ set up an
>>Escape handler and the user presses Escape. What if a program is
>>in a long loop (doing file stuff) and the user presses Escape
>>and nothing happens? they'll press Break and make just as much
>>of a mess.
>>    
>>
> 
>There are many instances where pressing Escape "does nothing",
>because the computer is in the middle of something and hasn't got
>to the end and checked the escape flag yet.
> 
>  *SAVE name 0+1000000
> 
>isn't going to respond to the Escape flag being set until it has
>finished.  PLOT 96 (draw a circle) isn't going to check the Escape
>flag until it has stopped drawing. A really impatient user could
>get bored at any time and press Break. If the user presses Break
>they deserve whatever they get. 
> 
>  
>
I don't mean things like that I mean if, for instance a C program is 
stuck in a
long processing loop. Or a program has been ported from linux (unlikely I
know ;)) that expects to get a SIG_INT when you're sick of it...

>>Also on many you've got to be careful about what you expect to
>>be safe; structures may be half updated, variables not correctly
>>set (although this is probably worse in 6502 as even a simple
>>increment on a 16bit no. will take a number of instructions).
>>    
>>
> 
>If you abort on the background Escape event in the middle of:
> 
>  strcpy(src,dst);
> 
>then the destination memory will be left in an inconsistant state.
> 
>  
>
During the signal handler yes. This as far as I understand is true in many
circumstances on other platforms and signal handlers should take this into
account.

> 
> 
>  
>
>>It looks as if there are two camps on this, those that dont want any form of
>>out-of-band signals sue to escape and those that do. I think I may put
>>all this
>>stuff in the BBC library but have it compile-time switchable some how
>>(either
>>when compiling the end program or when compiling the library).
>>    
>>
> 
>That's the solution I was working towards with Small-C. Let the
>programmer chose whether to use os_checkescape() themselves, or
>allow the Escape event to abort the program instead of setting the
>Escape flag.
> 
>I'm now thinkinking of adding another os_* escape function, that
>does something like:
> 
>os_something()
>{
>if !os_checkescape() return(void);
>os_byte(126, 0);
>os_error(17, "Escape");
>}
> 
>so mainline code can just call os_something() and have the error
>generation done for it if an escape state is set.
>  
>
That will be available (when I've finished the os_... veneers in cc65) too
hopefully. I was thinking of doing something along the lines of !OSLib
with xos_... returning a pointer to a err, errstr, 0 block or os_ form
aborting to os

Before I go off and do that I think it would be worth us synchronising
our os_... APIs. I've done a first crack but mostly in assembler at
moment for use by the C library. I'm happy to re-do (or use yours if
they're suitable for cc56)

> 
>Now I've got my BBC hard drive interface working, I really should
>copy the C compiler over to is and do some more work on it.
> 
>  
>
I know this is off topic but how well do these work? I'm definitely 
interested
in having one here! (Please reply by private email to this one or we'll 
be miles
off topic!)
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.