Re: Power: blink-cursor-mode is a pig

[Daniel Colascione]

On 12/30/11 11:10 PM, Eli Zaretskii wrote:
>> From: YAMAMOTO Mitsuharu <address@hidden>
>> Date: Sat, 31 Dec 2011 12:47:19 +0900
>> Cc: address@hidden,
>>  address@hidden
>>
>> BTW, stopping/suspending timers does not avoid Emacs to wake up
>> in a short period on some ports, depending on how its `select'
>> emulation is implemented.  At least, this applies to the NS port
>> because it does periodic polling inside its `select'
>> implementation when there are some subprocesses or network
>> connections.

Why? Some Cocoa limitation?

>> The Mac port does not have this drawback.  I'm not
>> sure about the W32 port.
> 
> If my reading of w32proc.c is correct, the w32 port blocks inside the
> call to WaitForMultipleObjects for the same time interval as the
> timeout specified in the call to `select' (redirected to `sys_select'
> on w32).  But this only blocks the main thread, the one that runs
> Lisp; the input thread that processes messages delivered to the Emacs
> frames cannot be blocked (doing so could cause deadlock to the entire
> system), so it continues running and processing messages.
> 

Right. cygw32 also uses MsgWaitForMultipleObjects (because
/dev/windows is in the select(2) set), so it behaves the same way as
the NT port.  In both, the UI thread will still receive messages, but
Windows takes pains to not send out useless message broadcasts.  Other
than these broadcasts, a program is only woken to receive a message
when something specifically sends it a message.  If there's no system
activity, or the only activity is unrelated to Emacs, Emacs won't
receive any messages and won't wake up.

signature.asc
Description: OpenPGP digital signature