Mac OS X - Hang / C-g problem patch

[Steven Tamm]

I just found some free time on my hands and got back around to working 
on the problem where in the carbon gui, C-g does not interrupt 
synchronous subprocesses.  This caused much consternation and after 
checking with some people at apple, there was no easy way.  The 
alternatives were to finish my Jaguar/MT UI patch (which I won't go 
into), or to make all blocking reads be in a separate thread.

This patch overrides read to call sys_read.  sys_read will call 
darwin's read if inhibit_window_system, noninteractive, if the file 
descriptor is not FIFO, or if the file descriptor is non-blocking.  So 
it only differs when blocks with pipes and sockets.  It works by 
spawning a worker thread that handles the read while waiting on a 
MPQueue (chose this instead of pthread_cond for simplicity).  When a 
potentially hanging read is started, it posts a message to the worker 
threads queue and then blocks for an event coming back from the worker 
thread and also KeyUp events.  If the worker thread event comes back to 
the main thread, it returns like normal.  If a keyup event comes in, it 
is tested to see if it is the quit_char, and if so, the worker thread 
is signalled and Fsignal is called to unroll the call.  It seems to 
work and hopefully it plugs a large hole.

Issues:
1.  Uses fstat and fcntl way too often.  These calls aren't 
extraordinarily expensive and I didn't notice a difference, but your 
mileage may vary.
2.  Traps keyUp instead of keyDown.  This behavior is broken because it 
makes emacs think C-g has been called twice.  But it makes things much 
simpler.  Otherwise, the main thread would have to dispatch all events 
to the kbd_buffer, which with the current event handling is an issue.  
If we switched to Carbon Event Handers, this would be a non-issue (in 
fact there would be less code).
3.  Only works when quit_char is C-g.  There is docs on how to fix it, 
but I didn't want to wait.
4.  Only works on darwin (due to use of pthread_kill).  I probably 
should have put in an ifdef...

Not tested:
1.  Sending random signals to the emacs process to see if the reads 
continue.  There may need to be some checking in signal handlers 
elsewhere to cause the secondary thread to break.
2.  Memory leaks.

I would appreciate any/all Mac OS X developers to try the patch and let 
me know how it goes.

-Steven

carbon_quit_char.patch
Description: Binary data

P.S.  This patch also contains the mac_check_bundle code I was playing 
around with to get emacs from the command line to start the GUI.