[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#50043: 28.0.50; USABLE_SIGOI undef code paths do not work correctly
From: |
Ken Brown |
Subject: |
bug#50043: 28.0.50; USABLE_SIGOI undef code paths do not work correctly |
Date: |
Mon, 15 Nov 2021 14:26:08 -0500 |
User-agent: |
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 |
On 11/15/2021 12:24 PM, Eli Zaretskii wrote:
Date: Mon, 15 Nov 2021 10:19:32 -0500
Cc: 50043@debbugs.gnu.org
From: Ken Brown <kbrown@cornell.edu>
x_get_foreign_selection (Lisp_Object selection_symbol, Lisp_Object target_type,
Lisp_Object time_stamp, Lisp_Object frame)
{
[...]
wait_reading_process_output (secs, nsecs, 0, false,
reading_selection_reply, NULL, 0);
I think wait_reading_process_output gets stuck for 2 seconds in a call to select
(actually xg_select because I'm testing a gtk build). This is independent of
the fact that x-selection-timeout is 2 seconds; it happens even if
x-selection-timeout is 0. select returns after 2 seconds because the poll_timer
fires.
Sorry, I don't understand: select waits for up to 2 seconds because
that's what we ask it to do, and those 2 sec do come from
x-selection-timeout. If x-selection-timeout is zero, select is not
supposed to wait at all, so why does it? What am I missing?
Setting x-selection-timeout to zero actually makes the timeout infinite:
if (time_limit < 0 || nsecs < 0)
wait = MINIMUM;
else if (time_limit > 0 || nsecs > 0)
{
wait = TIMEOUT;
now = current_timespec ();
end_time = timespec_add (now, make_timespec (time_limit, nsecs));
}
else
wait = FOREVER; <<<<<<<<<<<<<<<<<<<<<<
If x-selection-timeout is zero and you really want select to use a timeout of
zero, you have to specify a negative value for nsecs. [This strikes me as very
counterintuitive and a poor design decision.] x_get_foreign_selection should
probably be changed to account for this, since the default value of
x-selection-timeout is in fact zero, and clearly the intention was not to have
an infinite wait in this case. There's a comment in x_get_foreign_selection
that says "don't wait forever".
On systems with SIGIO, select returns as soon as X events occur, because
SIGIO is signaled.
Which X event is that? something related to Emacs and selections, or
just a random event which simply happens at that time?
I guess it's whatever X event is supposed to come in reply to the call
XConvertSelection (display, selection_atom, type_atom, target_property,
requestor_window, requestor_time);
in x_get_foreign_selection. I don't anything about how I/O works under X, so I
can't be more specific.
Anyway, AFAIU, the wait is supposed to end because XTread_socket reads
a SelectionNotify event, and that modifies the cell for which we
wait. What I'm not sure I understand is how are we supposed to call
XTread_socket when we are stuck inside select all the time?
We're never stuck for more than 2 seconds [when there's no SIGIO] because
poll_timer fires and either sends SIGALRM or makes timerfd read ready. Either
way, select returns, and the next iteration of the main loop checks for input
and checks for a cell change.
We certainly don't want to always skip the select call, but would it make sense
to use a very short timeout for select in that case? Or maybe someone has a
better idea.
Making timeout shorter might be the solution, but I'd like to
understand the problem better first.
Ken
- bug#50043: 28.0.50; USABLE_SIGOI undef code paths do not work correctly, Ken Brown, 2021/11/15
- bug#50043: 28.0.50; USABLE_SIGOI undef code paths do not work correctly, Eli Zaretskii, 2021/11/15
- bug#50043: 28.0.50; USABLE_SIGOI undef code paths do not work correctly,
Ken Brown <=
- bug#50043: 28.0.50; USABLE_SIGOI undef code paths do not work correctly, Eli Zaretskii, 2021/11/17
- bug#50043: 28.0.50; USABLE_SIGOI undef code paths do not work correctly, Ken Brown, 2021/11/17
- bug#50043: 28.0.50; USABLE_SIGOI undef code paths do not work correctly, Eli Zaretskii, 2021/11/17
- bug#50043: 28.0.50; USABLE_SIGOI undef code paths do not work correctly, Ken Brown, 2021/11/17
- bug#50043: 28.0.50; USABLE_SIGOI undef code paths do not work correctly, Eli Zaretskii, 2021/11/17
- bug#50043: 28.0.50; USABLE_SIGOI undef code paths do not work correctly, Ken Brown, 2021/11/17