octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: signal handling


From: John W. Eaton
Subject: Re: signal handling
Date: Thu, 14 Nov 2002 21:10:25 -0600

On 14-Nov-2002, Paul Kienzle <address@hidden> wrote:

| On Thu, Nov 14, 2002 at 03:59:45PM -0600, John W. Eaton wrote:
|
| > OK, so this "double interrupt" will only be required when
| > debug_on_interrupt is true and we are inside foreign code that would
| > normally jump out of the signal handler, correct?
| 
| __long__ running foreign code.  Short running foreign code (e.g., a small
| matrix multiply) will quickly get to the next statement and the debugger
| will pick it up before the user has a chance to press Ctrl-C twice.  

Right.

This also brings up the question of when to even bother setting up for
siglongjmp.  We have two ways to call Fortran code.  One is to make a
direct call using the F77_FUNC macro (for name mangling) from autoconf
and the other is to make a call using F77_XFCN, defined in
libcruft/misc/f77-fcn.h.  This macro does all the work of setting up
for siglongjmp and the possibility of errors in the Fortran code.
It's relatively safe, but expensive.  It probably makese sense for
calls to LSODE, but not calls to DERFC.  So I think we are only using
F77_XFCN for the potentially expensive calls now (I just changed a few
more simple calls in liboctave/lo-specfun.cc to use F77_FUNC).  OTOH,
there is no code like this (yet):

  if (problem_size > some_threshold)
    F77_XFCN (dgemm, DGEMM, (args, for, dgemm, ...));
  else
    F77_FUNC (dgemm, DGEMM) (args, for, dgemm, ...);

which would avoid all the setup costs if we think the problem is small
enough to be computed quickly.  I don't think there is any way to
guess this for iterative solvers like LSODE, but it would probably be
possible for things like matrix multiply, inversion, etc.

| It might be nice to let the user know which foreign function is active when
| Ctrl-C is pressed the first time, but I/O during signal handling sounds
| like a bad idea.

Right.  I think it's best to do as little as possible in the signal
handlers.  My only excuse for the way the code was originally written
is that I was in a hurry.  I figured that if it was important enough,
it would eventually be fixed.  According to this entry in ChangeLog.1,
it's only taken about 10 years:

  Wed Jun 24 15:09:36 1992  John W. Eaton  (address@hidden)

        * Version 0.10.

        * Cheesy signal handler added to catch interrupts.

jwe



reply via email to

[Prev in Thread] Current Thread [Next in Thread]