[Openmcl-devel] string-output-stream thread unsafety with hunchentoot (ccl, darwin/x86-64)

Gary Byers gb at clozure.com
Sat Apr 11 00:14:09 PDT 2009

<http://trac.clozure.com/openmcl/ticket/450> suggests that until
fairly recently it wasn't doing this correctly.

Now that it's doing it correctly, the question of why bordeaux-threads
wants to create a thread which doesn't have standard initial bindings
remains.  (To be fair, the documentation's a little murky: it refers
to DEF-STANDARD-INITIAL-BINDING, which doesn't seem to be documented,
and it doesn't say something like "you should really understand the
implications of this option before using it, and if you understand
them, you probablqy don't want to use it.")

According to the bordeaux-threads API documentation,
alist of symbols and forms; the documentation suggests that it's
initialized in some (possibly platform-dependent) way, but in
CCL it seems to be an empty list.

The function CCL::STANDARD-INITIAL-BINDINGS returns a similar
alist (of symbols and functions/closures).  There are about 30
entries on that list (and there could plausibly be several more;
printer control variables would be good and obvious candidates.)
I'd have to guess that a similar set of standard per-thread
bindings exists in other implementations, and I think that it'd
be difficult for a portable threads package to understand what the
consequences of not binding these variables would be.  (Some of
the stuff on CCL's list is pretty esoteric, but some of it's less
so:  (GENSYM) expects to increment a thread-local binding of
*GENSYM-COUNTER*, for instance.)

I think that the CCL documentation should be changed to discourage the
casual use of :USE-STANDARD-INITIAL-BINDINGS NIL, and bordeaux-threads
should either avoid passing this option or incorporate the value
returned by (CCL::STANDARD-INITIAL-BINDINGS) into its

BTW, the bordeaux-threads test case that fails seems to do so because
it's not really sure whether the CDRs of the pairs on the
*DEFAULT-SPECIAL-BINDINGS* alist are forms or functions; that failure
doesn't seem on first glance to be CCL-specific.

On Fri, 10 Apr 2009, Raffael Cavallaro wrote:

> On Apr 10, 2009, at 4:25 PM, R. Matthew Emerson wrote:
>> I've recently noticed that some code is creating threads without
>> standard initial bindings.  The most recent bordeaux-threads sources
>> seem to do this in openmcl.lisp:
>> (defun %make-thread (function name)
>>   (ccl:process-run-function (list :name name :use-standard-initial-
>> bindings nil)
>>                             function))
>> This is probably not a great idea...
> Maybe this is why bordeaux-threads doesn't pass all its tests under ccl;
> or not - it doesn't pass all tests under lispworks either…
> Raffael Cavallaro, Ph.D.
> raffaelcavallaro at mac.com
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel

More information about the Openmcl-devel mailing list