[GBBopen-developer] Portable threads fix for SCL

[Douglas Crosher]

Hello Dan,

Attached is a revised patch for the SCL, taking into account very recent
GBBopen commits.

Some suggestions for the portable threads library:

all-threads: this function is of limited use because threads may
exit after the call but before the result is used.  The SCL has a
function to map over all threads and ensure they do not exit.

thread-alive-p: this function is of limited use because the thread
may exit after the call but before the result is used in which case
it would be wrong.  Of some use for development and diagnosis.

with-timeout: this is generally unsafe and should not be used in
deployed applications.  It is also of limited development value
so I suggest just removing it.

%%get-lock%%, condition-variable: is there a real need for locks
and condition variables to be standard-objects?  Wouldn't
applications just be able to encapsulate them in standard-objects
if necessary?  Perhaps the intention is that classes include the
lock class as a mixin class for objects needing a lock, but then
what about an object needing two or more locks?  The design also
requires 'with-lock-held etc to work on condition variable, but
condition-variables are not locks...  Suggest keeping it simple
and separating locks and condition variables, then there is no
need for the standard-objects and the %%get-lock%% hack.

make-lock: The SCL also supports read-write locks.

thread-holds-lock-p: The SCL is built on POSIX threads which does
does not support this operation.

atomic-*: The SCL tries to use an atomic instructions to update
the place which is fast and safe but it only supports a limited
range of places, otherwise it must use an exclusive execution
context which is slow and fragile.  These macros are a legacy of
the old MP style, and perhaps should just be removed so that new
applications use locks.

without-lock-held:  The SCL reports the whostate only when waiting
to acquire the lock.  Consider adding a note that this should not
be used on recursively held locks for which it will be ineffective.

kill-thread: killing a running thread is in general unsafe.
Consider marking this function as unsafe, and advising developers
to use a cooperative system for thread exit such as checking a
flag at safe points.

run-in-thread: interrupting another thread and running arbitrary
code is in general unsafe.  The other thread could be holding an
important lock and deadlock.  Consider marking this function as
unsafe and not recommended for deployed applications.

throwable-sleep-forever, awaken-throwable-sleeper, hibernate-thread,
awaken-thread: unsafe, deployed applications should not be using
these, and I suggest just removing them.

make-condition-variable: should also accept a name for the condition
variable and also the name for the lock.

condition-variable-wait, condition-variable-wait-with-timeout:
should accept a whostate to help developers.

condition-variable-signal, condition-variable-broadcast: should not
require the lock to be held.  The safety is application dependent and
the broadcast can always be moved outside the lock.

scheduled-function: This seems to be portable code built on the threads
library which may be better placed elsewhere.

Regards
Douglas Crosher


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

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gbbopen-scl-patch2.txt
Url: http://GBBopen.org/pipermail/gbbopen-developer/attachments/20081023/66e276b6/attachment.txt