Critical sections and marking of free cells

[NIIBE Yutaka <gniibe@etl.go.jp>]

Mikael Djurfeldt writes:
 > In Guile, at most places where we make new smobs, we have pieces of
 > code like this:
 > 
 > SCM_NEWCELL (z);
 > SCM_DEFER_INTS;
 > SCM_SETCAR (z, scm_tc16_<name>);
 > SCM_SETCDR (z, <malloced memory>);
 > SCM_ALLOW_INTS;
 > 
 > It seems to me that these critical sections can be removed (that is,
 > we can remove SCM_DEFER/ALLOW_INTS) if we remove one line (846) from
 > gc.c:
[...]

Rather, I suggest considering remove of all such critical regions
protected by SCM_DEFER_INTS/SCM_ALLOW_INTS.  Current design of signal
handling in Guile is not so good, IMHO.

In (current implementation of) Guile, the default behavior is allowing
interrupts, which complicates many things.  It's something like this:

	As interrupts are allowed almost anywhere, there are possible
	situations where interrupts messes it up.  Watch out and
	protect yourself!

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.

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.

Opinions?

# Critical regions in threads environment is another issue...
-- 
Niibe Yutaka