Re: SCM_DEFER_INTS versus error

[Tom Lord]

    > From: Marius Vollmer <address@hidden>

Have things _really_ diverged so far that the following no longer
applies?   Just a word of caution:



    > The whole DEFER/ALLOW business is anachronistic (in my view at least)
    > and should go away.  Originally, it was used to mark sections of code
    > that could not tolerate being interrupted, at a time when POSIX
    > signals could run Scheme code right from the signal handler and that
    > Scheme code could invoke continuations or throw to a catch.

More specifically, they marked segments of code during which the heap
and flow-control could be in an inconsistent state as far as the usual
macros, gc, etc. were concerned.  That's an "extended" notion of
"inconsitent state" -- it included data structures and system state
that most of scheme didn't care about at all but that had to be
correlated with scheme heap state and flow of control.

    > SCM_DEFER_INTS would, well, defer the execution of signal handlers
    > until the next ALLOW_INTS.  Originally, it had nothing to do with
    > threads.

It did more than that, at least in the late days of when I was
maintainer.  For example, some C functions were safe to invoke within
the dynamic context of DEFER/ALLOW, others were not.  It was a handy
hack, that shook out many bugs, to:

      a) add a declaration in the body of each function that indicated
         when it could be safely run

      b) write an analyzer that roughly parsed the C code, did flow
         analysis, and labeled each call as "known ok", "known bogus", 
         or "too complex to analyze".


(Have you dropped the SCM_INTS_{ENABLED,DISABLED,INDIFFERENT} decls?!?)


    > I don't think we should keep the current meaning of DEFER/ALLOW.
    > Instead, we should make them noops and deprecate their usage.  We
    > should be able to make them noops right now.  Mikael, do you agree?

Traditionally, as an example, between DEFER/ALLOW, the
pointer-to-malloced-data in an object such as string was not required
to be valid.   Consequently, GC had to be excluded between
DEFER/ALLOW.


    > We have a different model for signal delivery now: Scheme signal
    > handlers are always deferred and are run by SCM_TICK, when it is safe
    > to do so.

    > So there no longer is the danger of code being interrupted in a
    > massive way (of course, C signal handlers still run asynchronously,
    > but they are careful not to mess things up).

Isn't there still a danger of bogusly calling a function that can, for
example, invoke GC at a point in the code at which the heap is in a
bogus state?   DEFER/ALLOW is useful, at least, for finding that
statically or at least noticing it dynamically.

In short, there's an extensible bunch of invariants that characterize
the heap and flow-control state.  Modules that add new tyeps and
functions can add new invariants.  The dynamic segments between
DEFER/ALLOW are where (and only where) those invariants can be
violated.

One way to look at it that might be helpful:  you have a kind of
virtual machine with the scheme heap as its store.   That VM has an
infinitely extensible set of macro-instructions as new C code is
added.   C itself is a kind of "micro-code" and the DEFER/ALLOW pairs 
mark the boundaries between macro-isntructions.

Say, do you still have REDEFER/REALLOW?   

-t