Re: SYNC_INPUT and 23.1.

[Stefan Monnier]

>>>>> Are there any plans to make SYNC_INPUT the default for 23.1?
>>>>> 
>>>>> That's a good idea.  Any objection?
>>>>> 
>>>> 
>>>> Sinc there has been no objections, I enabled this by default.  You can
>>>> pass --disable-sync-input to configure if there is problems.
>>>> But I guess we soon will start take advantage of sync input so the
>>>> disabled case will become obsolete.  When we feel confident that sync
>>>> input works, I'll remove the non-sync-input code.
>>> 
>>> Is this just an X thing, or does it affect common code as well? Are there
>>> changes we should be making on other platforms to support SYNC_INPUT?
>>> 
>> I think Stefan can answer that best, AFAIK, he did the implementation.
>> I assumed it was an X thing.  Does other platforms use signals for the GUI
>> loop?

I must admint that I don't know what systems use what.  The SNYC_INPUT
code replaces the signal handlign code by a code that simply sets a flag
and then lets a few macros like QUIT and UNBLOCK_INPUT run the
real signal-handler code in case the flag is set.  I.e. this runs the
signal handler code synchronously rather than asynchronously.  The main
benefit is for malloc and friends.

For systems that use a separate thread to handle GUI events, SYNC_INPUT
should make no difference.


        Stefan