* Re: master af152ffab1: Don't freeze if the compositing manager crashes
@ 2022-07-30 6:03 Eli Zaretskii
2022-07-30 7:02 ` Po Lu
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2022-07-30 6:03 UTC (permalink / raw)
To: Po Lu; +Cc: emacs-devel
There are a few places in Emacs that wait for similar reasons, so my
suggestion is to do this like they do, i.e. by calling
wait_reading_process_output. The advantage is that we let other code
and other threads to run while we wait.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: master af152ffab1: Don't freeze if the compositing manager crashes
2022-07-30 6:03 master af152ffab1: Don't freeze if the compositing manager crashes Eli Zaretskii
@ 2022-07-30 7:02 ` Po Lu
2022-07-30 8:06 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: Po Lu @ 2022-07-30 7:02 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> There are a few places in Emacs that wait for similar reasons, so my
> suggestion is to do this like they do, i.e. by calling
> wait_reading_process_output. The advantage is that we let other code
> and other threads to run while we wait.
The problem here is Emacs doesn't just "wait" for an event, it has to
use X(Check)IfEvent to remove that single event from the event queue, in
effect processing it "out-of-order".
So unfortunately wait_reading_process_output doesn't quite fit the bill
here.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: master af152ffab1: Don't freeze if the compositing manager crashes
2022-07-30 7:02 ` Po Lu
@ 2022-07-30 8:06 ` Eli Zaretskii
2022-07-30 8:37 ` Po Lu
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2022-07-30 8:06 UTC (permalink / raw)
To: Po Lu; +Cc: emacs-devel
> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 30 Jul 2022 15:02:32 +0800
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > There are a few places in Emacs that wait for similar reasons, so my
> > suggestion is to do this like they do, i.e. by calling
> > wait_reading_process_output. The advantage is that we let other code
> > and other threads to run while we wait.
>
> The problem here is Emacs doesn't just "wait" for an event, it has to
> use X(Check)IfEvent to remove that single event from the event queue, in
> effect processing it "out-of-order".
>
> So unfortunately wait_reading_process_output doesn't quite fit the bill
> here.
Why not?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: master af152ffab1: Don't freeze if the compositing manager crashes
2022-07-30 8:06 ` Eli Zaretskii
@ 2022-07-30 8:37 ` Po Lu
2022-07-30 8:48 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: Po Lu @ 2022-07-30 8:37 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> Why not?
Because wait_reading_process_output will call read_socket_hook to read
events, and at that point it's too late to extract the event we want out
of the queue.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: master af152ffab1: Don't freeze if the compositing manager crashes
2022-07-30 8:37 ` Po Lu
@ 2022-07-30 8:48 ` Eli Zaretskii
2022-07-30 10:39 ` Po Lu
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2022-07-30 8:48 UTC (permalink / raw)
To: Po Lu; +Cc: emacs-devel
> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 30 Jul 2022 16:37:37 +0800
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > Why not?
>
> Because wait_reading_process_output will call read_socket_hook to read
> events, and at that point it's too late to extract the event we want out
> of the queue.
Why too late?
Anyway, your change freezes Emacs for a whole second, which doesn't
seem to be a good idea.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: master af152ffab1: Don't freeze if the compositing manager crashes
2022-07-30 8:48 ` Eli Zaretskii
@ 2022-07-30 10:39 ` Po Lu
0 siblings, 0 replies; 6+ messages in thread
From: Po Lu @ 2022-07-30 10:39 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Po Lu <luangruo@yahoo.com>
>> Cc: emacs-devel@gnu.org
>> Date: Sat, 30 Jul 2022 16:37:37 +0800
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > Why not?
>>
>> Because wait_reading_process_output will call read_socket_hook to read
>> events, and at that point it's too late to extract the event we want out
>> of the queue.
>
> Why too late?
Because read_socket_hook has already removed the event (which is
probably not the event we want) from the queue.
> Anyway, your change freezes Emacs for a whole second, which doesn't
> seem to be a good idea.
It only freezes in a rare situation, which is when the compositing
manager crashes after the user has explictly enabled frame
synchronization.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-07-30 10:39 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-30 6:03 master af152ffab1: Don't freeze if the compositing manager crashes Eli Zaretskii
2022-07-30 7:02 ` Po Lu
2022-07-30 8:06 ` Eli Zaretskii
2022-07-30 8:37 ` Po Lu
2022-07-30 8:48 ` Eli Zaretskii
2022-07-30 10:39 ` Po Lu
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).