Re: Semantics of UNIX Signal Handling in Guile

[Telford Tendys <telford@triangle.triode.net.au>]

> How about Guile?  It's designed well, but it complicates requirements
> of C code, much.  Perhaps it may be easy to write module for Python in
> C, as we don't need to care to be interrupted.  Futher, current Guile
> code has some parts where DEFER_INTS/ALLOW_INTS mismatch will occur
> when assert is failed.
> 
> Couldn't we consider the approach of Bash or Python, where signal
> handling routine just marks the flag and eval/print routine checks for
> pending signal?
> 
> Any comments?

You have put some good research work in here and I'm very impressed.

I have a few things to add:
Firstly, I'd like signals right out of the core and into some optional
add-on. At very least I'd like a simple enable/disable switch somewhere.
I know that's difficult but I'm trying to get cross compatability between
win32 platforms and unix and the win32 doesn't do signals in the same way.
One of the big portability snags when leaving unix is signals.

Secondly, error handling is done in guile in a very similar manner
to signals. Thus if your C routine does a malloc and then evaluates
some guile, then does a free, the free may not be called if there is
errors in the evaluated guile. I have a sneaking suspicion that DEFER_INTS
and ALLOW_INTS can actually be used to cope with this or does the
mismatch occur as mentioned above? Anyhow, my point is that signals
are not the only reason that makes it tricky to write guile code,
errors present the same problem.

Thirdly, when writing asynchronous code it is sometimes nice to use
an event model rather than a thread model. This is going to particularly
be the case with guile being grafted onto existing GUI code.
With an even model, you want signals to introduce an new event into
the main queue but not begin processing that event until the current
event is complete (i.e. all events are atomic). I realise that this
model can be implemented on top of the current signal handler system
but the user should have the option to implement it in their own way too
(thus my feeling that signal support should be an add-on to the core
rather than locked into it).

Finally, if a piece of C code already makes use of signals for it's own
purposes then it's difficult to adapt that code to using Guile because
Guile wants control over all of the signals. This must limit the
scope of Guile usage somewhat.

	- Tel