[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: |
Tue, 16 Nov 2021 19:44:56 +0200 |
> Date: Mon, 15 Nov 2021 14:26:08 -0500
> Cc: larsi@gnus.org, 50043@debbugs.gnu.org
> From: Ken Brown <kbrown@cornell.edu>
>
> >> 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:
Ah, I thought you meant a literally zero timeout, not the "zero means
infinite" one.
> > 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.
If the code is based on the premise that we check for selection when
we exit select, then I think on systems without USABLE_SIGIO we should
call wait_reading_process_output with a short timeout but in a loop,
so that the summary wait is still 2 sec, but we exit the loop as soon
as selection arrives because each call to wait_reading_process_output
has a much shorter timeout, say, 25 msec. WDYT?
- 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, 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
- 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