[Top][All Lists]
[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
- [Gcl-devel] Inefficient unsigned 32-bit arithmetic?, dshardin, 2004/06/23
- Re: [Gcl-devel] Inefficient unsigned 32-bit arithmetic?, Camm Maguire, 2004/06/23
- [Gcl-devel] gcl_signal, Mike Thomas, 2004/06/25
- Re: [Gcl-devel] gcl_signal, Michael Koehne, 2004/06/25
- Re: [Gcl-devel] gcl_signal, Camm Maguire, 2004/06/28
- RE: [Gcl-devel] gcl_signal, Mike Thomas, 2004/06/28
- [Gcl-devel] Re: gcl_signal, Mike Thomas, 2004/06/25
- Re: [Gcl-devel] Re: gcl_signal,
Michael Koehne <=
- Re: [Gcl-devel] Re: gcl_signal, Mike Thomas, 2004/06/25
- Re: [Gcl-devel] Re: gcl_signal, Michael Koehne, 2004/06/26
- Re: [Gcl-devel] Re: gcl_signal, Camm Maguire, 2004/06/28
- Re: [Gcl-devel] Re: gcl_signal & sockets, Michael Koehne, 2004/06/28
- RE: [Gcl-devel] Re: gcl_signal & sockets, Mike Thomas, 2004/06/28
- Re: [Gcl-devel] Re: gcl_signal & sockets, Camm Maguire, 2004/06/29
- Re: [Gcl-devel] Re: gcl_signal & sockets, Camm Maguire, 2004/06/29
- Re: [Gcl-devel] Re: gcl_signal, Camm Maguire, 2004/06/28
- RE: [Gcl-devel] Re: gcl_signal, Mike Thomas, 2004/06/28
- Re: [Gcl-devel] Re: gcl_signal, Camm Maguire, 2004/06/29