[Openmcl-devel] Problems with openMCL slime and Aquamacs (Mac OS X)

[Gary Byers]

I was going to reply to this and say something like "good idea, but
the type-caching mechanism must be thread-safe; how else could it
have worked for several years without causing problems ?"  Good thing
I glanced at the code before sending that ...

One of the ways in which it's not thread-safe involves a function
that clears its contents: changes to the type hierarchy may invalidate
at least some cached entries, and CCL::CLEAR-TYPE-CACHE conservatively
clears all cached entries when this occurs.  It does so by setting
all elements in a pair of parallel vectors to 0; if some other thread
had found a "key" (type specifier) in one vector and the vectors
got zeroed by another thread before the first thread returned the
corresponding "value" (CTYPE object), the first thread would return
0 instead of a reasonable value.  This sounds vaguely familiar somehow ...

There are other ways to lose and there are several (simple, obvious ...)
ways to enforce thread safety.  I'm not sure which of those ways is
best performance-wise, but if we don't do something and have a chance
of returning gibberish here, it doesn't matter how quickly we return
that gibberish.


On Sat, 24 Oct 2009, Tobias C. Rittweiler wrote:

> Philippe Sismondi <psismondi at arqux.com> writes:
>
>> I should emphasize that the problem is intermittent, from which I
>> infer that any of ccl, slime, and asdf or some combination may still
>> be the culprit(s). What I mean is, for example, loading asdf in raw
>> ccl (without emacs+slime) does not prove that it's not asdf, since
>> sometimes asdf loads fine when using emacs+slime+ccl. And so forth....
>
> Given that it's non-deterministic, there's the possibility that the
> cache clobbering Gary talked about may be due to multiple accesses from
> threads.
>
> Could you try putting (setf swank:*communication-style* nil) into your
> ~/.swank.lisp (which makes Slime not use threads), and see if you can
> reproduce the problem?
>
>  -T.
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>