Re: BLOCK_INPUT on Mac OS X

[cabo@informatik.uni-bremen.de (Dr. Carsten Bormann)]

Two millicenturies ago,
Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>>> Can you try the patch below?  Beware, IIRC, if emacs_read is ever
>>> called somewhere where BLOCK_INPUT is set, this could introduce
>>> other problems.
>
>> It didn't work for me on both Mac OS X and GNU/Linux.  Actually,
>> `read', which has not received any data, is silently restarted after
>> processing a signal because:
>
>>   1. That's a default behavior in BSD systems. (Mac OS X)
>>   2. SA_RESTART is set in `sys_signal' if POSIX_SIGNALS is
>>      defined. (GNU/Linux)
>
> Duh!  I guess we'd need to unset SA_RESTART when we use SYNC_INPUT.
>
>> If SA_RESTART is not set in `sys_signal', synchronous processes can be
>> quit on GNU/Linux (with your patch).  But that breaks "Emacs mostly
>> works better with restartable system services" (from a comment in
>> `sys_signal').
>
> I'm curious what this comment refers to.  Anybody remembers what are the
> problems with non-restartable system services?  Is it possible that those
> problems are not applicable in the case where we use SYNC_INPUT
> (i.e. when we keep signal handlers to the strict minimum)?

As you are probably aware, restartable system calls were added to BSD
to enable job control -- without restartable system calls, suspending
a process (which is mapped to a signal internally) might mean that a
write(2) was cut short and nothing in the (predominant sloppy) code
would notice.  Also, most programs just weren't prepared to handle
EINTR returns from read(2).  (This is from memory, about a quarter
century ago...)

I don't know how well the Emacs code checks the return values on
system calls like write.  Of course, I'd assume, very very well.

So I think we should pick up the somewhat stale discussion and do
what's necessary to arrive at a stable Emacs.  Why don't we just set
BROKEN_SA_RESTART with SYNC_INPUT?

Gruesse, Carsten