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

[Nix <ni...@es...>]

On Mon, 25 Nov 2002, Paul Kienzle yowled:
> On Mon, Nov 25, 2002 at 08:35:11PM +0000, Nix wrote:
>> ... oh, damn and blast, SuperLU is C. I didn't notice and thought it was
>> C++.
> 
> Maybe all is not lost.  I forgot that we are recompiling superlu ourselves.
> When I tested this a couple of years ago, I found that I could do something
> like:

[throw through C]
> This seems to still work.  I don't know what to throw though.

Yes, this will always work; we'd be in some trouble being ISO C++
compliant otherwise --- the Standard requires throws through
std::qsort() and std::bsearch() to work, in s17.3.4.8.2 --- and POSIX
has a good few callback-style routines, which it would be nice to allow
exceptions to be thrown through.

I guess we could have done it by reimplementing qsort() and bsearch() in
libstdc++-v3, but that would have been ugly.

(Obviously, exception throws through non-GCC-compiled C code won't work,
except on the IA64, which has hardware support for exceptions. :) )


One problem is that this is a rather GCC-specific solution :( I'm sure
there are compilers out there that *don't* support throwing through C
code.

But luckily we don't need to do this at all. (See below.)

> 
> 	octave_throw_interrupt_exception() ?
> 	octave_throw_bad_alloc() ?

Neither.

> If this works, I can push out a new octave-forge very soon,
> but Ctrl-C will not be responsive within superLU.
> 
> For Ctrl-C we need to put OCTAVE_QUIT in all the inner loops of *.{cc,h}

No need :)

> and wrap calls to superLU with BEGIN/END_INTERRUPT_WITH_EXCEPTIONS.
> At least I think that's what we are supposed to do.

No need for any of that; the _IMMEDIATELY_ variants of those macros set
up a setjmp() / throw layer. The Octave signal handlers in
src/sighandlers.cc spot that we're inside an _IMMEDIATELY_ wrapper
(because `octave_interrupt_immediately' is nonzero) and (sig)longjmp
there for us.

> It's not clear how we can clean up a superLU malloc which was interrupted
> during initialization.  I believe that's why garbage collection was
> invented.

You can't clean that up, but then we've *never* been able to clean that
up. At least this way destructors for C++ objects get called :)

(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.)

Leaving the bit below because it's still relevant:

>> OK, C that counts as foreign code, so calls into SuperLU will require
>> BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE /
>> END_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE wrapped around them. That
>> should let the code flow when interrupted by SIGINT within SuperLU go
>> 
>> SIGINT -> signal handler in octave's src/sighandlers.cc ->
>> octave_jump_to_enclosing_context() -> longjmp() to the
>> END_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE -> Octave's toplev.cc.
>> 
>> > The macros to do this are in quit.h, but I don't know the exact magic.
>> 
>> I think I've decrypted it.
>> 
>> > Let me know if you are going to persue this, because it is top of my list
>> 
>> It's top of mine too. Patch in an hour or so (this box is running rather
>> slowly right now, alas, and it would be inurbane for me to antinice
>> everyone else into oblivion).

I got stalled by wondering how best to wrap *all* calls into SuperLU. I
guess that a thin C++ wrapper around SuperLU is indicated, each of which
does careful BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE /
END_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE calls.

--- oh, this is only needed in computationally expensive stuff. In cheap
calls we can just ignore it and leave the calls undecorated, because the
user won't interrupt in there and won't notice the delay even if he
does. (Decorating such calls is probably a bad idea, actually, because
the setup and teardown for the _INTERRUPT_IMMEDIATELY_ stuff isn't
free.)

So probably that's just a few potentially-expensive SuperLU calls we
need to decorate.

Any idea which they are? I haven't much of a clue :)

-- 
`I keep hearing about SF writers dying, but I never hear about SF
 writers being born.  So I guess eventually there'll be none left.'
                                    -- Keith F. Lynch