Re: master 18ec3fcce9: Restore pending_signals at a point in the DND event loop

Re: master 18ec3fcce9: Restore pending_signals at a point in the DND event loop

[Stefan Monnier]

> @@ -9674,7 +9675,12 @@ x_dnd_begin_drag_and_drop (struct frame *f, Time time, Atom xaction,
>  			 &next_event, &finish, &hold_quit);
>  #endif
>  #endif
> +      /* The unblock_input below might try to read input, but
> +	 XTread_socket does nothing inside a drag-and-drop event
> +	 loop, so don't let it clear the pending_signals flag.  */
> +      signals_were_pending = pending_signals;
>        unblock_input ();
> +      pending_signals = signals_were_pending;
>  
>        if (x_dnd_movement_frame)
>  	{

This is pretty ugly.
Why is it that it "does nothing"?  Any hope we can move this restoration
of `pending_signals` closer to the code that "does nothing"?


        Stefan

Re: master 18ec3fcce9: Restore pending_signals at a point in the DND event loop

[Po Lu]

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

> This is pretty ugly.
> Why is it that it "does nothing"?  Any hope we can move this restoration
> of `pending_signals` closer to the code that "does nothing"?

No, because we don't know the prior value of `pending_signals' in that
code.

In general, the interaction between async input and the event loop run
during a drag is pretty confusing, especially on GTK+.  This solves the
last case of SelectionRequest events being mishandled (because the
selection events are being stored in the wrong `hold_quit' buffer)
during a drag-and-drop operation on GTK.

Re: master 18ec3fcce9: Restore pending_signals at a point in the DND event loop

[Stefan Monnier]

Po Lu [2022-04-17 11:55:23] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> This is pretty ugly.
>> Why is it that it "does nothing"?  Any hope we can move this restoration
>> of `pending_signals` closer to the code that "does nothing"?
> No, because we don't know the prior value of `pending_signals' in that
> code.

How bout the first question?

Also, I'm pretty sure the real answer isn't "no" because we can surely
move it to the place where `pending_signals` is changed and that is closer
at least in terms of "dynamic distance".

> In general, the interaction between async input and the event loop run
> during a drag is pretty confusing, especially on GTK+.

And we should make this complexity much more explicit in the code rather
than add magic hacks linked via occasional comments.


        Stefan

Re: master 18ec3fcce9: Restore pending_signals at a point in the DND event loop

[Po Lu]

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

> Also, I'm pretty sure the real answer isn't "no" because we can surely
> move it to the place where `pending_signals` is changed and that is closer
> at least in terms of "dynamic distance".

Changing `process_pending_signals' to take into account a small
technicality in the X11 drag-and-drop code seems much less clean to me
than three lines of code accompanied by an explaining comment.

Re: master 18ec3fcce9: Restore pending_signals at a point in the DND event loop

[Stefan Monnier]

> Changing `process_pending_signals' to take into account a small
> technicality in the X11 drag-and-drop code seems much less clean to me
> than three lines of code accompanied by an explaining comment.

To me, those 3 lines are impenetrable.

So, if you could explain (or show) what it would take to do it more like
what I suggest, maybe I can at least improve the comment.


        Stefan

Re: master 18ec3fcce9: Restore pending_signals at a point in the DND event loop

[Po Lu]

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

>> Changing `process_pending_signals' to take into account a small
>> technicality in the X11 drag-and-drop code seems much less clean to me
>> than three lines of code accompanied by an explaining comment.
>
> To me, those 3 lines are impenetrable.
>
> So, if you could explain (or show) what it would take to do it more like
> what I suggest, maybe I can at least improve the comment.

That unblock_input might call XTread_socket, which returns in this
specific case since data is passed from the nested event loop to its
caller via the hold_quit parameter to handle_one_xevent, and the
hold_quit given to the read socket hook is not correct.

So XTread_socket always returns without reading input whenever the
nested event loop is active.  This is fine, but pending input might not
be read if the nested event loop stops after that, since
process_pending_input clears pending_signals, even if nothing was
actually read.