[GBBopen-developer] Portable threads fix for SCL

[Douglas Crosher]

The 'without-lock-held implementation is not correct for the SCL.  This macro looks
problematic. A throw from within does not re-acquire the lock so unsafe code could
execute in the outer context.  Using 'unwind-protect may help, but a lock acquired
in a cleanup could be hard to debug.  Further the whostate for the original lock
acquisition is not available within the locked context on the SCL, or CMUCL, and it is
only set when waiting for the lock; is it actually set in this context on other CL
implementations?

The SCL :mp package is actually more recent that the :thread package and was added
to aid compatibility with old code, so its use is as intended.

For 'make-cond-var the :auto-free default is 't which would be the safest general
value, so it may be best to just leave it off.  Some more changes may be necessary
for the SCL and I'll follow up soon.

Regards
Douglas Crosher

Chun Tian (binghe) wrote:
> Hi, GBBopen & Dr. Corkill
> 
> Recently I'm testing my lisp projects on SCL (which just be freed for 
> non-commercial use days ago). I found current portable-threads package 
> (SVN r573) cannot be compiled correctly with SCL (1.3.8.1), some points:
> 
> * conditional variable class & related function haven't been defined for 
> SCL
> 
> * there's a small typo in macro WITHOUT-LOCK-HELD
> 
> Attach is my trivial patch, please review it. With this patch I can 
> compile & load it correctly (no test yet). But I don't know if I should 
> add ":AUTO-FREE T" when I create the conditional-variable.
> 
> And, it seems that all thread-related functions in SCL are moved to 
> THREAD package, but most code in portable-threads is still using the 
> "old" MULTIPROCESSING (MP) package. I don't know from which version SCL 
> add the THREAD package, maybe just the same time with the :PTHREAD in 
> SCL's *FEATURES*. Should we change them to new package?
> 
> Regards,
> 
> Chun Tian (binghe)
> 
> 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.