[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