1- Why does get-mutex have a with-interrupts? as the FIXME note above
says, it's probably wrong. Nikodemus, can you comment?
2- Because of it, I think with-active-processes-lock should NOT
:allow-with-interrupts t least a subtle race condition occurs. Cyrus,
does that fix your issues?
3- While I stand by my previous analysis that what SBCL does with
run-program is probably bad taste, I am proven full of shit in
asserting that it had an obvious race condition in the multithreaded
case: with-active-processes-lock does try (through with-system-mutex)
to both achieve mutex between each thread's main code and signal
handlers (with without-interrupts) and achieve mutex between threads
(with get-mutex) -- in a way I was too dumb to previously guess or
understand. It's somewhat expensive but it should work and provide
race-condition-free low latency reaping of zombies (assuming get-mutex
is free from race-condition, and if one never forks but through
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
The difference between a contemporary liberal and a socialist is that to a
liberal the most beautiful word in the English language is 'forbidden',
whereas to a socialist the most beautiful word is 'compulsory'.
-- John McCarthy
On Sun, Jan 11, 2009 at 7:28 PM, Faré <fahree@...> wrote:
> 1- Why does get-mutex have a with-interrupts? as the FIXME note above
> says, it's probably wrong. Nikodemus, can you comment?
It is problematic only on lutex platforms (which is to say no problems
If it did not have it, waits on lutexes could not be interrupted,
which would make all sorts of lock-related problems harder to debug
(can't interrupt a waiting thread to backtrace it, etc.)
The reason it is problematic is if an interrupt occurs and unwinds
from %LUTEX-LOCK call *after* the underlying lock has been acquired --
in which case MUTEX-VALUE doesn't get updated correctly. (There may be
other ways for an interrupt to mess up %LUTEX-LOCK, but that's the
None of this is an issue when futexes are used: FUTEX-WAIT has a
WITH-INTERRUPTS as well, but because it doesn't actually grab the lock
unwinding from there is not a problem, etc.
> 2- Because of it, I think with-active-processes-lock should NOT
> :allow-with-interrupts t least a subtle race condition occurs. Cyrus,
> does that fix your issues?
Aside from the aforementioned MUTEX-VALUE bogosity I don't see a race
there, but neither do I see why it would /need/
:ALLOW-WITH-INTERRUPTS: at a glance none of the places where it is
used seem like the indefinite waits would be expected.