SYNC_INPUT and 23.1.

SYNC_INPUT and 23.1.

[Jan Djärv]

Hello.

Are there any plans to make SYNC_INPUT the default for 23.1?

	Jan D.

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?


        Stefan

Re: SYNC_INPUT and 23.1.

[Jan Djärv]

Stefan Monnier skrev:
>> 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.

	Jan D.

Re: SYNC_INPUT and 23.1.

[Jason Rumney]

Jan Djärv wrote:
>
>
> Stefan Monnier skrev:
>>> 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?

Re: SYNC_INPUT and 23.1.

[Jan Djärv]

Jason Rumney skrev:
> Jan Djärv wrote:
>>
>>
>> Stefan Monnier skrev:
>>>> 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?

	Jan D.

Re: SYNC_INPUT and 23.1.

[Jason Rumney]

Jan Djärv wrote:
>
>
> Jason Rumney skrev:
>> Jan Djärv wrote:
>>>
>>>
>>> Stefan Monnier skrev:
>>>>> 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?

Windows uses window messages for input, which arrive to Emacs on a 
separate thread for each frame. They are then pushed into the Lisp input 
queue. The process differs slightly from signal handlers in that no 
interrupt occurs when input arrives, we have to poll the frame's message 
queue periodically, but because this is performed by a separate thread, 
it is asynchronous from the point of view of the main Lisp thread. But I 
recall there are some problems caused by the fact that unlike signal 
handlers, the message handling thread does not interrupt the main Lisp 
thread, which have already been worked around on Windows, so the 
SYNC_INPUT changes may or may not be relevant.

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

Gnus problem?

[Johan Bockgård]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

[raw header]

Cc: Jan =?iso-8859-1?Q?Dj=1FFFFFFFFFFFFFFFrv?= <jan.h.d@swipnet.se>,
                           ^^^^^^^^^^^^^^^

Stefan, what's up with this?  A similar thing happened in your reply to
one of my posts in another thread.

-- 
Johan Bockgård

Re: Gnus problem?

[Stefan Monnier]

> Cc: Jan =?iso-8859-1?Q?Dj=1FFFFFFFFFFFFFFFrv?= <jan.h.d@swipnet.se>,

> Stefan, what's up with this?  A similar thing happened in your reply to
> one of my posts in another thread.

Sorry, it's a bug in one my local hacks, but I haven't had the time to
look into it yet.


        Stefan

Re: SYNC_INPUT and 23.1.

[Richard Stallman]

I've been pretty much convinced that SYNC_INPUT should be the default.
My only doubt is about whether it leads to long delays in display updating
in situations where that would not occur without SYNC_INPUT.
I know this won't be as bad as I formerly though, but is it bad?

What have people observed?

Re: SYNC_INPUT and 23.1.

[Jan Djärv]

Richard Stallman skrev:
> I've been pretty much convinced that SYNC_INPUT should be the default.
> My only doubt is about whether it leads to long delays in display updating
> in situations where that would not occur without SYNC_INPUT.
> I know this won't be as bad as I formerly though, but is it bad?
> 
> What have people observed?
> 

I've used SYNC_INPUT for some months now, and I haven't noticed any delays.
Display updating in X over a slow link is a bigger problem IMHO.

	Jan D.

Re: SYNC_INPUT and 23.1.

[Richard Stallman]

    I've used SYNC_INPUT for some months now, and I haven't noticed any delays.

I think the case in which this might cause delays is if you expose part of an
Emacs window which was hidden, while Emacs is not idle.

Re: SYNC_INPUT and 23.1.

[Jan Djärv]

Richard Stallman skrev:
>     I've used SYNC_INPUT for some months now, and I haven't noticed any delays.
> 
> I think the case in which this might cause delays is if you expose part of an
> Emacs window which was hidden, while Emacs is not idle.
> 

Yes.  However, the X server may do backing store, so I don't see it anyway.

	Jan D.

Re: SYNC_INPUT and 23.1.

[Stefan Monnier]

>     I've used SYNC_INPUT for some months now, and I haven't noticed
>     any delays.

> I think the case in which this might cause delays is if you expose part of an
> Emacs window which was hidden, while Emacs is not idle.

That's not a problem.  SYNC_INPUT does not postpone X11 event processing
to the time of event processing.  It just postpones it until the next
QUIT or UNBLOCK_INPUT macro.  I.e. the C code constantly polls
a variable to see if a signal has arrived.


        Stefan

Re: SYNC_INPUT and 23.1.

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 11 Mar 2008 11:36:46 +0100, Jan Djärv <jan.h.d@swipnet.se> said:

> 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?

Window system events in the Carbon(+AppKit) port are not
signal-driven.  But in order to notice C-g, window resize and so on
even while the Lisp interpreter is busy or waiting for synchronous
process output, it uses polling by SIGALRM.  This is essentially the
same as what some systems without SIGIO (such as some versions of
Solaris) even with X11, and SYNC_INPUT also makes sense in such
platforms.

BTW, with SYNC_INPUT, some `immediate_quit' cases can no longer be
quit with C-g.  Does anyone working on this?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: SYNC_INPUT and 23.1.

[Stefan Monnier]

> BTW, with SYNC_INPUT, some `immediate_quit' cases can no longer be
> quit with C-g.  Does anyone working on this?

As soon as I get a report,


        Stefan

Re: SYNC_INPUT and 23.1.

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 11 Mar 2008 09:16:46 +0100, Jan Djärv <jan.h.d@swipnet.se> said:

> 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.

Even with SYNC_INPUT, atimer functions (except poll_for_input)
may still call malloc in the signal handler context.  So
emacs_blocked_malloc etc. were actually meaningful even in
SYNC_INPUT environments.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: SYNC_INPUT and 23.1.

[Stefan Monnier]

>> 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.

> Even with SYNC_INPUT, atimer functions (except poll_for_input)
> may still call malloc in the signal handler context.

That needs to be fixed, then.


        Stefan

Re: SYNC_INPUT and 23.1.

[Jan Djärv]

Stefan Monnier skrev:
>>> 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.
> 
>> Even with SYNC_INPUT, atimer functions (except poll_for_input)
>> may still call malloc in the signal handler context.
> 
> That needs to be fixed, then.
> 

I've changed atimers so they are not called in signal handler context.

	Jan D.

Re: SYNC_INPUT and 23.1.

[Stefan Monnier]

>>>> 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.
>> 
>>> Even with SYNC_INPUT, atimer functions (except poll_for_input)
>>> may still call malloc in the signal handler context.
>> 
>> That needs to be fixed, then.
>> 

> I've changed atimers so they are not called in signal handler context.

Thanks,


        Stefan

Re: SYNC_INPUT and 23.1.

[Richard Stallman]

    Even with SYNC_INPUT, atimer functions (except poll_for_input)
    may still call malloc in the signal handler context.  So
    emacs_blocked_malloc etc. were actually meaningful even in
    SYNC_INPUT environments.

Why is that?  Can it be eliminated?

Re: SYNC_INPUT and 23.1.

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 12 Mar 2008 13:51:35 -0400, Richard Stallman <rms@gnu.org> said:

>     Even with SYNC_INPUT, atimer functions (except poll_for_input)
>     may still call malloc in the signal handler context.  So
>     emacs_blocked_malloc etc. were actually meaningful even in
>     SYNC_INPUT environments.

> Why is that?  Can it be eliminated?

Here's the list of atimer functions (the third argument to
start_atimer):

  xg_process_timeouts, poll_for_input, show_hourglass,
  create_process_1, x_process_timeouts

Among them, show_hourglass, x_process_timeouts, and
xg_process_timeouts will call async-signal unsafe functions.

I think show_hourglass can be deferred until the next QUIT.  But not
sure about x_process_timeouts and xg_process_timeouts.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp