[Top][All Lists]

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

Re: [Gcl-devel] Re: gcl_signal

From: Mike Thomas
Subject: Re: [Gcl-devel] Re: gcl_signal
Date: Sat, 26 Jun 2004 10:19:01 +1000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)

Thanks Michael.

I'll leave the ins and outs of that one to you and Camm!

Hope all is well as the sun comes up in your part of the world - it's a beautiful sunny morning here.

Mike Thomas

Michael Koehne wrote:
Moin Mike Thomas,

(that is, SIGUSR2 (inserted in signals_handled) is not installed, but
SIGPIPE and SIGFPE (not present in the signals_handled vector) are at least
passed into the function even if not dealt with.)

This I leave to you to consider. I think it is only a cosmetic issue now, but it is late here so...

  my idea of signals_handled is that this behavior is on purpose -
  signals who are not in signals_handled are handled directly in C
  (e.g. the segmentation_catcher), while those who are in signals_handled
  need special handling, because they are calling Lisp code, and might
  change garbarge collector and other things.

  The question is, if this is still true. The code looks, as if it was
  needed to get the sigusr1 signal of gcl-tk handled without a race
  condition. Later sigpipe was added, but here a later change used
  FEerror to raise condition, and now those two functions should go
  into the signals_handled array, as they are using FEerror, which
  is calling Lisp.

5. in "main.c" install_segmentation_catcher also runs gcl_signal on SIGSEGV,
which is, also, not present in the signals_handled vector.

Not any more.

  sigsegv should just check stack and call error() - i wonder that
  they did install a signal for it - just dump core would be right
  behavior normaly.

Bye Michael

reply via email to

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