Re: [Gcl-devel] Re: gcl_signal

[Camm Maguire]

Greetings!

Michael Koehne <address@hidden> writes:

> Moin Mike,
> 
> > I'll leave the ins and outs of that one to you and Camm!
> 
>   the signal code is something I dont like to touch before reading its
>   implications a few more times. But sigfpe1 & sigpipe smell ugly :
> 
>   sigfpe1 is not delayed by main_signal_handler, but running directly,
>   calling FEerror - breaking in garbage collector state ...
>   sigpipe is calling perror(""); and FEerror next - the empty string
>   for perror really stinks for half patched/half broken ...
> 
>   so I suggest to add both signals to signals_handled, and to remove
>   the perror("") from sigpipe. I think, i can construct a test condition
>   for a sigpipe and user installed sigpipe, lets look how it works out.
> 

Test conditions for the signal handlers would be very useful in
reverse engineering the intent.  In particular, the handling
possibilities of SIGALRM and SIGIO could have implications for a
possible (re-)implementation of server sockets in gcl.

Take care,

> 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 mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah