gcl-devel
[Top][All Lists]
Advanced

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

Re: [Gcl-devel] Re: gcl_signal


From: Michael Koehne
Subject: Re: [Gcl-devel] Re: gcl_signal
Date: Fri, 25 Jun 2004 17:41:50 +0200
User-agent: Mutt/1.3.28i

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
-- 
  mailto:address@hidden             UNA:+.? 'CED+2+:::Linux:2.4.22'UNZ+1'
  http://www.xml-edifact.org/           CETERUM CENSEO WINDOWS ESSE DELENDAM




reply via email to

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