Re: reentrant port table stuff

[Marius Vollmer]

Chris Cramer <address@hidden> writes:

> On Sat, Jul 28, 2001 at 02:43:15PM +0200, Marius Vollmer wrote:
> > Hmm, I don't think this is completely right.  I think you can't
> > perform `extensive' operations like scm_must_malloc when interrupts
> > are disabled.  Could you try to reformulate your patch so that only
> > `simple' operations are performed while interrupts are disabled?
> > Maybe mallocs.h can help to protect the entry struct until it is
> > safely stuffed into the table.
> 
> Are there rules written down somewhere for when you should/shouldn't
> disable interrupts, and what you should/shouldn't do when they're
> disabled?

Not that I'm aware of, at least not for the current implementation of
DEFER_INTS/ALLOW_INTS.  There is a short paragraph in the docs of
guile-iii.

We definitely need to change this.  Ok, I've put this on top of my
todo list.

> There are a few other places where scm_must_malloc, scm_must_realloc,
> or scm_must_free are called with interrupts disabled.

Yeah.  Rereading the code somewhat, I guess it's OK.  What I'm worried
about is that scm_must_malloc can call the GC, which runs the `after
gc' hook, which can run arbitrary C or Scheme code.  I don't think it
is good to assume that arbitrary code can be called with interrupts
disabled.

But, I'm not even really sure yet what kind of interrupts we are
talking about...

Thinking in this direction leads me straight to the question: what
kind of threading model do we want to have?  Disabling interrupts is
not the right way to construct critical sections for a
multi-processing threading model.

I myself am not really a friend of multi-processing and communicating
via shared memory.  I would only provide cooperative threadin within
one address space, and request that multi-processing code communicated
via more high-level means than plain memory accesses.

Err, whatever...