Re: [OctDev] [PATCH] CVS-octave-forge and GCC3.2

[Paul K. <pki...@ja...>]

On Wed, Nov 27, 2002 at 01:38:22PM -0600, John W. Eaton wrote:
> On 26-Nov-2002, Nix <ni...@es...> wrote:
> | (Hell, there's a worse case than that: the SIGINT is asynchronous, so it
> | can arrive in the middle of a malloc(). If it does that, we're
> | completely screwed and the heap is fubared. But this, too, has always
> | been the case, and there don't seem to be many bug reports that can be
> | traced to screwed heaps. So I guess this is rare enough to ignore.)
> 
> Right.  This is one of the reasons it is bad to jump out of a signal
> handler.  If instead the signal handler sets some flag indicating that
> it has been called and returns so that the jump only happens when it
> is safe, we are OK.  But unless SuperLU is written with signal
> handling in mind, then this will require some changes.

I do find it ugly having to decide for each loop whether or not an octave
quit is desired.  The alternative approach is garbage collection is it
not?  Assuming sigsetjmp/siglongjmp work as advertised, then with a 
garbage collection system you could eventually clean up after an interrupt.
You would have to be careful to write your resource allocator code safely:

allocate_resource() {
	allocating = 1
	grab resource and register it
	allocating = 0
	if (interrupted) siglongjump
}

interrupt_signal() {
	if (interrupted) return
	if (allocating) interrupted=1
	else siglongjmp
}

eval_once() {
	if (sigsetjmp()) collect garbage
	else do next operation
}


Then the bulk of your code, and your numeric code in particular, doesn't
have to glance obsessively at the quit flag to see whether the user has
become bored of waiting yet.  This should make your code faster and easier to
write.  In this case, resource allocation include things like unwind_protect
as it is currently used to protect global variables as well as fopen, and malloc.

Would this be any better than sprinkling BEGIN/END_INTERRUPT and OCTAVE_QUIT
all over the code?

- Paul