From: Ken Brown <kbrown@cornell.edu>
To: Eli Zaretskii <eliz@gnu.org>
Cc: larsi@gnus.org, 50043@debbugs.gnu.org
Subject: bug#50043: 28.0.50; USABLE_SIGOI undef code paths do not work correctly
Date: Mon, 15 Nov 2021 14:26:08 -0500 [thread overview]
Message-ID: <b9422588-4e5f-b0ea-fdb2-74de443471ee@cornell.edu> (raw)
In-Reply-To: <83czn12uz1.fsf@gnu.org>
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
next prev parent reply other threads:[~2021-11-15 19:26 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-13 11:56 bug#50043: 28.0.50; USABLE_SIGOI undef code paths do not work correctly Lars Ingebrigtsen
2021-08-13 13:16 ` Eli Zaretskii
2021-08-13 14:31 ` Lars Ingebrigtsen
2021-08-13 15:51 ` Eli Zaretskii
2021-08-14 11:52 ` Lars Ingebrigtsen
2021-11-15 15:19 ` Ken Brown
2021-11-15 17:24 ` Eli Zaretskii
2021-11-15 19:26 ` Ken Brown [this message]
2021-11-16 17:44 ` Eli Zaretskii
2021-11-16 23:06 ` Ken Brown
2021-11-17 7:41 ` Lars Ingebrigtsen
2021-11-17 14:25 ` Ken Brown
2021-11-17 13:14 ` Eli Zaretskii
2021-11-17 14:19 ` Ken Brown
2021-11-17 14:34 ` Eli Zaretskii
2021-11-17 14:59 ` Ken Brown
2021-11-17 16:56 ` Eli Zaretskii
2021-11-17 17:25 ` Ken Brown
2021-11-17 17:37 ` Eli Zaretskii
2021-11-17 17:45 ` Ken Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b9422588-4e5f-b0ea-fdb2-74de443471ee@cornell.edu \
--to=kbrown@cornell.edu \
--cc=50043@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=larsi@gnus.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.