[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