[Openmcl-cvs-notifications] Commit: ccl/lisp-kernel
gb at clozure.com
gb at clozure.com
Thu Dec 14 15:50:02 MST 2006
Affected files with versions:
x86-exceptions.c,1.59
-----------------------------------
Details:
Update of /usr/local/tmpcvs/openmcl-dev/ccl/lisp-kernel
In directory clozure.com:/tmp/cvs-serv11907/lisp-kernel
Modified Files:
x86-exceptions.c
Log Message:
Go back to using the pseudo_sigreturn mechanism on Darwin, since
doing a real sigreturn from a fake context may not be reliable.
When handling an interrupt with a partially created temp stack
frame, do the right thing. (That basically means reset the
frame before calling out and recreating it if we return from the
callout.)
Handle SIGQUIT on the altstack, to provide a way of forcibly
terminating threads that's a bit more GC-safe than doing it
via #_pthread_cancel.
Note the tcr of the gc thread on gc entry; if an exception
happens in that thread, print a message and sleep for 60
seconds.
Note that there's still a race condition here: if thread A
gets an exception and thread B gets the mach_exception_lock
(to GC) before the exception thread can handle the message,
we deadlock (thread A would be suspended in the kernel and
can't respond to a suspend signal.) We can tell that this
has happened and make a good guess as to why it happened,
but dealing with it will require some thought. (If we've
already issued a suspend signal and eventually raise the
suspended thread's resume semaphore, it'll suspend and resume
once the mach exception thread makes it runnable. Who
cleans up its exception context in that case ? Does it
matter ?)
More information about the Openmcl-cvs-notifications
mailing list