[Ecls-list] Special symbols that might benefit from implicit locking or thread-local bindings
Juan Jose Garcia-Ripoll
juanjose.garciaripoll at googlemail.com
Mon Aug 1 08:09:20 UTC 2011
On Mon, Aug 1, 2011 at 5:32 AM, Matthew Mondor <mm_lists at pulsar-zone.net>wrote:
> I audited the symbol.d and package.d code today, and wrote down some
> notes about possible future improvements.
It would be nice if someone did this for the whole of the Hyperspec :-)
> Although GENSYM is more often used in the compile phase (which is
> single-threaded, at least for now), it can also be used by
> multithreaded user code at runtime. Because GENSYM is standard,
> it's unlikely that user code would expect to have to use a lock to
> avoid its internal race conditions around *GENSYM-COUNTER*. So
> possibly that GENSYM should implicitely use a lock, held the whole time
> between the getf and setf.
Doesn't the fact that the user may change *gensym-counter* invalidate the
purpose of the lock? The compiler itself sets *gensym-counter* to 0, binding
it locally so there may be no race condition there, since the symbols are
> I wondered if a lock was also required for *PACKAGE* access in
> IN-PACKAGE, but I'm unsure, as theoretically every thread has its own
> local *PACKAGE*; but I'm unsure where this binding gets created, I only
> see the ECL_SETQ to set the new package, I might have missed a LET-like
> binding creation operation. I see a ecl_bds_bind() call for
> *current-process* only in process.d. There's some bindings related
> code in process_alloc() but I don't think it handles this either.
This is indeed more important: what bindings should become local for a
thread by default. Currently the list of variables that become thread-local
is by default empty. Maybe we should at least add *package* to it? Maybe
also create a global binding with the default list of variables so that each
invocation of make-process uses it by default? What do you think?
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ecl-devel