[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SCM_DEFER_INTS versus error
From: |
Tom Lord |
Subject: |
Re: SCM_DEFER_INTS versus error |
Date: |
Fri, 19 Sep 2003 13:34:34 -0700 (PDT) |
> 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