[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: |
Eli Zaretskii |
Subject: |
bug#50043: 28.0.50; USABLE_SIGOI undef code paths do not work correctly |
Date: |
Mon, 15 Nov 2021 19:24:02 +0200 |
> 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?
> 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?
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 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.
Thanks.
- 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 <=
- 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/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