Re: master fa52782f5c: Make timer_check even more resilient

Re: master fa52782f5c: Make timer_check even more resilient

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> +  block_input ();
> +  turn_on_atimers (false);
>  
>    /* We use copies of the timers' lists to allow a timer to add itself
>       again, without locking up Emacs if the newly added timer is
> @@ -4646,6 +4648,8 @@ timer_check (void)
>    else
>      idle_timers = Qnil;
>  
> +  turn_on_atimers (true);
> +  unblock_input ();

Does input really have to be blocked around this?

The call to `unblock_input' will end up reading async input, which might
not be safe at that spot.  (The X11 drag and drop code used to suffer
from this problem, and debugging the resulting crashes was not easy.)

Re: master fa52782f5c: Make timer_check even more resilient

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

> Does input really have to be blocked around this?

I read the bug report again, and please ignore that.

Re: master fa52782f5c: Make timer_check even more resilient

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> +  block_input ();
>> +  turn_on_atimers (false);
>>  
>>    /* We use copies of the timers' lists to allow a timer to add itself
>>       again, without locking up Emacs if the newly added timer is
>> @@ -4646,6 +4648,8 @@ timer_check (void)
>>    else
>>      idle_timers = Qnil;
>>  
>> +  turn_on_atimers (true);
>> +  unblock_input ();
>
> Does input really have to be blocked around this?
>
> The call to `unblock_input' will end up reading async input, which might
> not be safe at that spot.  (The X11 drag and drop code used to suffer
> from this problem, and debugging the resulting crashes was not easy.)

There was apparently a segfault due to an atimer being called while the
copy-sequence was doing done, but it does indeed seem very unlikely.
The inhibit_quit there also seems unlikely to actually do anything.

Can you have a look at the bug thread and see what you think?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master fa52782f5c: Make timer_check even more resilient

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> There was apparently a segfault due to an atimer being called while the
> copy-sequence was doing done, but it does indeed seem very unlikely.
> The inhibit_quit there also seems unlikely to actually do anything.
>
> Can you have a look at the bug thread and see what you think?

I already did and asked a question there.  AFAIK atimers cannot run
Lisp, so it's probably the call to inhibit atimers that's extraneous.

Thanks.