> Message-ID: <4299ACB3.5040203@brahms.demon.co.uk> dominic beesley <dominic@brahms.demon.co.uk> wrote: > I guess really the main worry is that I'm in the middle of > updating one of the file structures. I'm trying to work out if an > Escape is ever delivered in the middle of an OS operation. In Yes, Escapes can happen at *any* time when IRQs are enabled. The foreground program should check for an escape state at safe points in the program, eg between BASIC statements, at the end or start of loops, after a received keypress. > which case it gets very messy. Otherwise I'll just try and make > sure that the cleanup code uses some kind of semaphore to protect > other file ops (and possibly delays the Escape handling until > after it has happened). Don't abort on Escape! It's so much easier. Just let Escape set its flag in the background. Let the foreground check for it. It's no good saying you'll close all open files (or files opened by the program) on an escape-induced abort. What if you abort halfway through a file delete? The directory may have been written to disk before the free space map has been written. Even worse, only one sector of the directory may have been written, destroying the catalogue! > so it means hanging off the interrupt vector somewhere. Also > there is no way of returning from BRK so I'm setting something There is, it's called setting up an error handler. In machine code you do it by setting BRKV to point to you error handler. In BASIC you do it by using ON ERROR. -- J.G.Harston - jgh@arcade.demon.co.uk - mdfs.net/User/JGH RISC OS Choices System - http://mdfs.net/Software/RISCOS ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Tue May 31 03:00:42 2005
This archive was generated by hypermail 2.1.8 : 2005-05-31 03:00:45 CEST