Re: [AD] trapping `exit'?

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


Peter Wang <tjaden@xxxxxxxxxx> writes:
> I was wondering if there was a way to trap the call to exit() or some
> signal, in order to cancel the call or maybe give Allegro a chance to kill 
> its keyboard handler?

Allegro tries to do that already: it hooks into atexit(), and takes over 
most of the interesting signals. I think the problem is that SVGAlib takes 
over lots of signals itself, overriding what Allegro has done with them. 
I've been trying to work around this in my SVGAlib driver, and it basically 
just involves putting them back again after you initialise it, but this will 
certainly be a problem if it aborts from inside the init code, as I don't 
think you have any way to hook into that.

You could always just check for root permissions first, and not even try the 
init unless they are available.

SVGAlib is also problematic because it unconditionally drops the root access 
when you initialise it. That is a problem if you ever want to shut it down 
and reinit it later, as you will have lost the rights to do this. I can't 
think of any way around this, though, so I think that will remain as a 
limitation of using it. Seems like rather an unfortunate thing for a library 
to do, when they don't even give you the option of whether you might want to 
keep those rights for other things!

btw. given that I'm working on a direct support for SVGAlib, is there really 
any point in using it though GGI as well? I think it is really only worth 
using GGI for the targets that we don't already natively support.


--
Shawn Hargreaves - shawn@xxxxxxxxxx - http://www.talula.demon.co.uk/
"A binary is barely software: it's more like hardware on a floppy disk."



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/