[Openmcl-devel] Exception in foreign context
Patrick May
patrick.may at mac.com
Sun Sep 13 13:11:51 PDT 2009
On Sep 13, 2009, at 2:08 PM, Gary Byers wrote:
> On Sun, 13 Sep 2009, Patrick May wrote:
>> > Error: value #<STRING-OUTPUT-STREAM #x30004197E41D> is not of the
>> expected type STRUCTURE.
>> > While executing: CCL::CREATE-STRING-OUTPUT-STREAM-IOBLOCK, in
>> process Hunchentoot worker (client: 67.86.101.207:62567)(29).
>
>
> This rings a bell; see:
>
> <http://clozure.com/pipermail/openmcl-devel/2009-April/009117.html>
>
> My recollection of that problem is that:
>
> - CCL expects a STRING-OUTPUT-STREAM to be (mostly) thread-private;
> in particular it expects a STRING-OUTPUT-STREAM to be closed from
> the same thread that created it. (A lot of that has to do with
> being able to cheaply recycle some of the resources that STRING-
> OUTPUT-STREAMS use and the use of a thread-specific special variable
> to do that recycling.)
>
> - The problem was occurring in that case/at that time not because code
> was violating the assumption, but because a threading library that
> Hunchentoot used was creating threads without "standard initial
> bindings"
> (including the binding of the thread-local variable used to do the
> freelisting.)
>
> The threads library (Bordeaux ?) was changed and the problem went
> away.
>
> The assumption that STRING-OUTPUT-STREAMs are short-lived and mostly
> thread-private
> still seems reasonable (in the sense that it's typical and
> reasonable to optimize
> for), but it's not clear that violating that assumption should lead
> to memory
> corruption. That hasn't been fixed (partly because the Hunchentoot
> problem
> seemed to be triggered by the threads library behavior and partly
> because the
> idea of closing a STRING-OUTPUT-STREAM from a thread other than the
> one that
> created it seemed like a pretty bizarre thing to do.) It still
> seems a bit
> bizzarre, but it's probably equally bizarre to not handle that case
> more sanely.
>
> In any case, it seems believable that you're running into the same
> problem; if
> so, using a newer version of the (Bordeaux ?) threads library will
> likely fix it.
Gary,
Thanks very much for your prompt and helpful replies. I'll give that
a try.
Regards,
Patrick
More information about the Openmcl-devel
mailing list