Re: Several questions.

[Marius Vollmer]

Dirk Herrmann <address@hidden> writes:

> On 20 Apr 2001, Marius Vollmer wrote:
> 
> > > * scm_smobs is a malloc'd array that gets resized for every new
> > >   smob.  With preemptive threading, this will not work well:  It would be
> > >   necessary to guard every access to scm_smobs with a mutex.
> > 
> > Does pthreads offer something like a atomic update for a pointer?
> > With such a thing, we could atomically swap in the new smobtable.
> 
> I don't think so.  The problem does not depend on whether the pointer can
> be updated atomically.  Assume thread A wants to print some smob
> object.  Thus, it has just read the value of scm_smobs, pointing to some
> memory region.  Exactly in this moment, thread B is activated.  B installs
> a new smob type, which means:  The old memory region gets freed due to the
> realloc.

I see, damn.  (I'm slowly but steadily forming the opinion that
preemptive threading and shared memory can't be good friends.)

Ok, I can't reliable think about thread issues, but I'd say we should
allocate the whole smob array at once.  I would prefer to use Goops
for the bulk of the user defined types in the future, so hopefully we
don't need to extend the number of smob types.

Doesn't the port table have the same issue, btw?

> >     $ guile
> >     ints already disabled (at smob.c:288)
> >     ERROR: Unbound variable: *top-level-lookup-closure*
> 
> [...]
>
> You should rather use the following make command:
>   make "CFLAGS=-g -DSCM_DEBUG_INTERRUPTS=1"
> which will only enable the debugging of the interrupt stuff, but will
> still leave all deprecated code in.

Ok!  Thanks!