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

[John W. E. <jw...@be...>]

On 27-Nov-2002, Paul Kienzle <pki...@ja...> wrote:

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

The method above requires doing something special for all resource
allocations and then undoing that at the point of deallocation.  This
would be in addition to whatever already happens in the constructor
and destructor (which now may or may not be called).

  * Which way adds less overhead?  It may be more expensive to
    add/delete tags in every constructor/destructor pair than it is to
    check the interrupt state in a few strategic locations.

  * Is it easier or harder to write and maintain?  Every allocation,
    not just memory allocations, must be tagged specially.

  * Is it more reliable?  It might not be practical to modify all the
    constructors for all the classes so that they can register the
    resources that they allocate)?

My guess is that the method above requires more care than the way
Octave currently works (with the signal handler setting the interrupt
state and OCTAVE_QUIT to check it).  If you omit OCTAVE_QUIT in some
long-running loop, Octave is just unresponsive to interrupts.  If you
forget to register an allocation, then we will have resource leaks,
and potentially, you could leave the interpreter in an inconsistent
state.

jwe