[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Mac OS X - Hang / C-g problem patch

From: Steven Tamm
Subject: Mac OS X - Hang / C-g problem patch
Date: Wed, 4 Dec 2002 10:06:10 -0800

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.

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.


Attachment: 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.
reply via email to

[Prev in Thread] Current Thread [Next in Thread]