Re: SCM_DEFER_INTS versus error

[Marius Vollmer]

Tom Lord <address@hidden> writes:

>     > From: Marius Vollmer <address@hidden>
>
> Have things _really_ diverged so far that the following no longer
> applies?

Yes, I would say so.

>     > 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.

Yes, your are right of course.  Not only interrupts could mess things
up, but they were the only asynchronous source of lossage.  The only
other source would be a programming error, right?

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

I didn't even know they were there, at some time!  So, yes, they are
gone, too.

> 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 now do this with careful coding only.  Still having the DEFER/ALLOW
markups in the code is helpful for statically checking this, as you
say.  Hmm...

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405