Re: Critical sections and marking of free cells

[Tel <telford@eng.uts.edu.au>]

> I think this problem similars to dangling memory references in
> explicit GC scheme (with GCPRO/UNGCPRO).  It's hard to preserve
> consisitency in the code, and it's very difficult to regenerate the
> problem and find actual bug.  I'm sceptical and don't think that all
> critical regions are protected well.  Not using heavily, we just
> haven't met the problem.

Quite true, someone posted not long ago about problems with SCM
and interrupts. I've had a few cases where hitting ^C to break a
long function evaluation caused the repl to hang but I couldn't
reproduce it, very frustrating but mostly I'm ignoring the problem.

I agree that the current situation is not satisfactory.

> In this summer, I posted here a little survey around signal handling
> in scripting languages.  My conclusion was that the one in Python is
> good.  Its defalut is masking all interrupts almost all the time and
> define explicitly the point to catch the interrupts.  This makes it
> simpler.
> 
> If we could define such well-defined interrupts point in Guile, I
> think that it's worth to considering remove of
> SCM_DEFER_INTS/SCM_ALLOW_INTS.

Firstly, there may be cases where applications want control of the
interrupts. I would say that the guile-core should NOT catch many
interrupts at all by default, just ^C for the REPL and maybe a
segmentation violation for debugging. What justification is there
for grabbing all of the interrupts except ``because it can''?

Naturally, there should be ways for guile to grab interrupts if
that is required by the user but it should not just wade in and snatch.

Secondly, fiddling with the interrupt mask is really not necessary
and is yet another thing that is likely to start fights with
application code. Why not just write a tiny subroutine that updates
a counter to indicate that an interrupt has occured? I suspect
that checking the counter somewhere in the evaluator is actually
faster than fiddling with interrupt masks and faster then DEFER/ALLOW
pairs. It is safe for the interrupt to come in at any time
because all it does is access the counter.

This is a simple solution, easy for application writers to understand,
easy to prove that it is correct, easy to write code for.

The only weakness is a longer interrupt latency but the difference
won't be huge and the overall throughput improvement caused by avoiding
DEFER/ALLOW should make up for it.

There is also a problem if an interrupt hits while we are deep inside
the user's C code doing something like a matrix inversion. The
latency could be very long indeed. Some simple gh_check_int() function
could be added to the user code to avoid this situation. It would
be optional anyhow and most people wouldn't be bothered without it
so no great shakes here.

	- Tel