[Openmcl-devel] bogus objects
ch-openmcl at bobobeach.com
Sun Nov 14 08:10:49 PST 2004
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
> is relatively new, or I didn't push things hard enough to encounter
> (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
> 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*
> ? (setq ccl::*gc-event-status-bits*
> (logior (ash 1 ccl::$gc-integrity-check-bit)
This is the kind of thing I was looking for. Thanks again.
More information about the Openmcl-devel