Re: [Sbcl-devel] CL:CLASS

[Daniel B. <da...@te...>]

Christophe Rhodes <cs...@ca...> writes:

> What this means: unless something goes horribly wrong, the next SBCL
> release (which /I/, at least, want to call 0.8.0) will no longer have

We talked a little about this on IRC.  For the benefit of list readers
who don't also IRC - and for posterity -

06:54:53 <Krystof> so the big question is: "what does the next version get called?"
06:55:07 <Krystof> 0.7.14.1? 0.8.0pre.1?
06:57:10 <Krystof> (well, maybe that's not the big question)
06:59:16 <wnewman> I haven't noticed any response to my mention of 0.8.0 on the mailing list, so it seems to be only you and I who care.
07:00:40 <wnewman> If the SB-PCL:CLASS stuff lands, and Dan either puts in threads or doesn't care, it's OK with me if the next release is 0.8.0, and it's ok with me if it takes more than a month.
07:00:40 <wnewman> which hopefully gives everyone concerned enough leeway

For the record, I am more likely to put in threads in this release
cycle (for x86 linux) than to not care.  I'm working on a sensible way
to do this that isn't #ifdef city and doesn't too horribly impact
people who just want a single-threaded system (single-threaded SBCL
will be slightly faster owing to not needing various locks, and to
having a symbol-value that doesn't need to do quite as weird things -
and will almost certainly be more stable, at least initially)

The mess is mostly in VOPS and in the runtime.  For example, 
the SymbolValue macro currently takes one argument, a pointer to the
symbol.  In the threaded version, it takes a second argument, which is
the thread context to look up per-thread values in.  I will probably
do this by changing SymbolValue to take two arguments in either case,
and ignore the second argument if SBCL has been compiled unithread.

I'll send some patches this way before I start committing the uglier
stuff, so people can comment on the proposed approach


-dan

-- 

   http://www.cliki.net/ - Link farm for free CL-on-Unix resources