[Openmcl-devel] bogus objects

[Cyrus Harmon]

On Nov 13, 2004, at 10:13 PM, Gary Byers wrote:

>> using ccl::make-lock and ccl::with-lock-grabbed seem to have
>> ameliorated the problem. I'm not convinced there aren't more gotchas
>> lurking, but I think the one I was seeing was due to multiple threads
>> trying to write to a global error stream at roughly the same time.
>
> I've run Araneida-based servers here relatively recently (~5 months
> ago) and didn't encounter this; either the shared usage of string 
> streams
> is relatively new, or I didn't push things hard enough to encounter 
> this.
> (Or both, I guess.)

Things seem to be OK until you do a combination of stupid things: 1) 
have pages the spit out error messages and 2) do things like rapidly 
quick on the forward button in a web browser to cause the browser to 
load multiple pages in rapid-fire succession. I suspect that this is 
the problem because 1) using the lock here makes the problem goes away, 
2) it matches Gary's description of a potentially problematic use of 
shared streams and 3) it coincides, roughly, with where I was getting 
some of the debugger messages and things on the corresponding stack 
traces.

> Threads and locks aren't part of CL (though many/most implementations
> offer them in some form or another.)  There are enough differences in
> those implementations that it's hard to come up with a universal
> portability layer; cross-platform packages that have to deal with
> threading issues usually offer their own portability layer that's
> adequate for the package's specific needs.

They may not be part of the CL spec, but they're clearly an important 
part of useful CL implementations like OpenMCL! Thanks!

>
>>
>> Any nice tools for checking memory integrity I should know about?
>
> Hmm ... that depends on what you mean by "nice".
>
> The symbol CCL::*GC-EVENT-STATUS-BITS* is allocated in a static
> memory area (yes, there is one, but there isn't an easy way to
> make other static areas) where the kernel/GC can find it.  The
> value of that variable is a fixnum, and some individual bits
> in that fixnum control GC behavior.  (In commercial MCL, this is/
> was used to control things like whether the GC should change the
> shape of the mouse cursor, etc.  There aren't a whole lot of
> bits that still make sense.)
>
> Setting the CCL::$GC-INTEGRITY-CHECK-BIT in CCL::*GC-EVENT-STATUS-BITS*
> [via:
>
> ? (setq ccl::*gc-event-status-bits*
>         (logior (ash 1 ccl::$gc-integrity-check-bit)
>                 ccl::*gc-event-status-bits*))
>

This is the kind of thing I was looking for. Thanks again.

Cyrus