On 20 July 2013 02:12, Cyrus Harmon <ch-sbcl@...> wrote:
> This is probably old news, but I saw SB-CONCURRENCY-TEST::DQ failing on Mac OS 10.8.4. It appears to be intermittent.
> This is SBCL 220.127.116.11-953e296, an implementation of ANSI Common Lisp.
Yeah. This is a long-standing one.
I forget the details, but
(1) I've dug down pretty deep on that one, and come up with nothing.
As if there was a race condition in the kernel -- but XNU sources at
least don't seem to be doing anything tricky in the area, so I don't
actually believe that: I suspect our mach handlers are at fault.
(2) Masking interrupts doesn't work correctly / reliably on OS X these
days inside pseudo-atomic. The SB-SPROF tests that are disabled tend
to tickle them. I think the main symptom is "interrupt already
pending" crashes. The mask is lost when returning from our mach
handlers. We have a hack in place that is supposed to take care of it,
but apparently Darwin changed from underneath us.
Unless someone feels truly at home with the mach stuff, I would
suggest trying to use normal BSD-style signal handling on Darwin as
well. I know we moved away from it because the emulation was too weak,
but maybe it has gotten better over the past few years?
The alternative would be going over the mach stuff with a fine comb.
Finally the not-marked-as-write-protected issue is as near as I can
tell harmless to ignore, at least as long as you're not flying an
airplane or operating medical equipment. If it keep tripping someone
up, there are a couple of C variables they can twiddle to change the
behaviour of the system when it runs across this situation.
From: Paul Khuong <pvk@pv...> - 2013-07-20 20:14:22
Nikodemus Siivola wrote:
> Unless someone feels truly at home with the mach stuff, I would
> suggest trying to use normal BSD-style signal handling on Darwin as
> well. I know we moved away from it because the emulation was too weak,
> but maybe it has gotten better over the past few years?