* Question about wait_reading_process_output @ 2015-06-05 9:49 Alex Bennée 2015-06-15 3:47 ` Stefan Monnier 0 siblings, 1 reply; 8+ messages in thread From: Alex Bennée @ 2015-06-05 9:49 UTC (permalink / raw To: emacs-devel Hi, I've been digging into the code trying to get an idea of why bug#16737 fires. My question is where in wait_reading_process_output does it ensure the various terminal socket reads are run? AFAICT the x-selection notifications come via this path. -- Alex Bennée ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Question about wait_reading_process_output 2015-06-05 9:49 Question about wait_reading_process_output Alex Bennée @ 2015-06-15 3:47 ` Stefan Monnier 2015-06-15 8:23 ` Tassilo Horn ` (2 more replies) 0 siblings, 3 replies; 8+ messages in thread From: Stefan Monnier @ 2015-06-15 3:47 UTC (permalink / raw To: Alex Bennée; +Cc: emacs-devel > I've been digging into the code trying to get an idea of why bug#16737 > fires. My question is where in wait_reading_process_output does it > ensure the various terminal socket reads are run? I see noone replied yet. I can't really help you because I don't know this code at all, but I really hope someone else will come along to help, Stefan ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Question about wait_reading_process_output 2015-06-15 3:47 ` Stefan Monnier @ 2015-06-15 8:23 ` Tassilo Horn 2015-06-15 8:23 ` bug#16737: " Tassilo Horn 2015-06-15 14:51 ` Eli Zaretskii 2 siblings, 0 replies; 8+ messages in thread From: Tassilo Horn @ 2015-06-15 8:23 UTC (permalink / raw To: Stefan Monnier; +Cc: 16737, Alex Bennée, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> I've been digging into the code trying to get an idea of why >> bug#16737 fires. My question is where in wait_reading_process_output >> does it ensure the various terminal socket reads are run? This doesn't really address your question but maybe it gives an indication. Since bug#16737 started occurring to be, I compile emacs with -DTRACE_SELECTION and then collect the output it delivers. The below output was gathered when I yanked into emacs where it always took 5 seconds (`x-selection-timeout') until the text I had previously copied from the browser was inserted. This seems to be another instance of the bug because actually the correct text has been inserted; it just took very long. Bye, Tassilo --8<---------------cut here---------------start------------->8--- 6019: Sent SelectionNotify: CLIPBOARD, target TARGETS (7511) 6019: x_stop_queuing_selection_requests 1 6019: x_handle_selection_event 6019: x_handle_selection_event 6019: x_start_queuing_selection_requests 1 6019: x_handle_selection_request: selection=CLIPBOARD, target=TARGETS 6019: XInternAtom LENGTH 6019: XInternAtom FILE_NAME 6019: XInternAtom CHARACTER_POSITION 6019: XInternAtom LINE_NUMBER 6019: XInternAtom COLUMN_NUMBER 6019: XInternAtom OWNER_OS 6019: XInternAtom HOST_NAME 6019: XInternAtom USER 6019: XInternAtom CLASS 6019: XInternAtom NAME 6019: XInternAtom SAVE_TARGETS 6019: Sending all 84 bytes 6019: Sent SelectionNotify: CLIPBOARD, target TARGETS (7512) 6019: x_stop_queuing_selection_requests 1 6019: x_handle_selection_event 6019: x_handle_selection_event 6019: x_start_queuing_selection_requests 1 6019: x_handle_selection_request: selection=CLIPBOARD, target=TARGETS 6019: XInternAtom LENGTH 6019: XInternAtom FILE_NAME 6019: XInternAtom CHARACTER_POSITION 6019: XInternAtom LINE_NUMBER 6019: XInternAtom COLUMN_NUMBER 6019: XInternAtom OWNER_OS 6019: XInternAtom HOST_NAME 6019: XInternAtom USER 6019: XInternAtom CLASS 6019: XInternAtom NAME 6019: XInternAtom SAVE_TARGETS 6019: Sending all 84 bytes 6019: Sent SelectionNotify: CLIPBOARD, target TARGETS (7513) 6019: x_stop_queuing_selection_requests 1 6019: x_handle_selection_event 6019: x_start_queuing_selection_requests 1 6019: x_handle_selection_request: selection=CLIPBOARD, target=TARGETS 6019: XInternAtom LENGTH 6019: XInternAtom FILE_NAME 6019: XInternAtom CHARACTER_POSITION 6019: XInternAtom LINE_NUMBER 6019: XInternAtom COLUMN_NUMBER 6019: XInternAtom OWNER_OS 6019: XInternAtom HOST_NAME 6019: XInternAtom USER 6019: XInternAtom CLASS 6019: XInternAtom NAME 6019: XInternAtom SAVE_TARGETS 6019: Sending all 84 bytes 6019: Sent SelectionNotify: CLIPBOARD, target TARGETS (7514) 6019: x_stop_queuing_selection_requests 1 6019: x_handle_selection_event 6019: x_handle_selection_clear 6019: x_handle_selection_event 6019: x_handle_selection_clear 6019: Get selection UTF8_STRING, type _EMACS_TMP_ 6019: Start waiting 5 secs for SelectionNotify 6019: Got event = 0 6019: Get selection UTF8_STRING, type _EMACS_TMP_ 6019: Start waiting 5 secs for SelectionNotify 6019: Got event = 0 6019: Received SelectionNotify 6019: Get selection STRING, type _EMACS_TMP_ 6019: Start waiting 5 secs for SelectionNotify 6019: Got event = 0 6019: Received SelectionNotify --8<---------------cut here---------------end--------------->8--- ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#16737: Question about wait_reading_process_output 2015-06-15 3:47 ` Stefan Monnier 2015-06-15 8:23 ` Tassilo Horn @ 2015-06-15 8:23 ` Tassilo Horn 2015-06-15 14:51 ` Eli Zaretskii 2 siblings, 0 replies; 8+ messages in thread From: Tassilo Horn @ 2015-06-15 8:23 UTC (permalink / raw To: Stefan Monnier; +Cc: 16737, Alex Bennée, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> I've been digging into the code trying to get an idea of why >> bug#16737 fires. My question is where in wait_reading_process_output >> does it ensure the various terminal socket reads are run? This doesn't really address your question but maybe it gives an indication. Since bug#16737 started occurring to be, I compile emacs with -DTRACE_SELECTION and then collect the output it delivers. The below output was gathered when I yanked into emacs where it always took 5 seconds (`x-selection-timeout') until the text I had previously copied from the browser was inserted. This seems to be another instance of the bug because actually the correct text has been inserted; it just took very long. Bye, Tassilo --8<---------------cut here---------------start------------->8--- 6019: Sent SelectionNotify: CLIPBOARD, target TARGETS (7511) 6019: x_stop_queuing_selection_requests 1 6019: x_handle_selection_event 6019: x_handle_selection_event 6019: x_start_queuing_selection_requests 1 6019: x_handle_selection_request: selection=CLIPBOARD, target=TARGETS 6019: XInternAtom LENGTH 6019: XInternAtom FILE_NAME 6019: XInternAtom CHARACTER_POSITION 6019: XInternAtom LINE_NUMBER 6019: XInternAtom COLUMN_NUMBER 6019: XInternAtom OWNER_OS 6019: XInternAtom HOST_NAME 6019: XInternAtom USER 6019: XInternAtom CLASS 6019: XInternAtom NAME 6019: XInternAtom SAVE_TARGETS 6019: Sending all 84 bytes 6019: Sent SelectionNotify: CLIPBOARD, target TARGETS (7512) 6019: x_stop_queuing_selection_requests 1 6019: x_handle_selection_event 6019: x_handle_selection_event 6019: x_start_queuing_selection_requests 1 6019: x_handle_selection_request: selection=CLIPBOARD, target=TARGETS 6019: XInternAtom LENGTH 6019: XInternAtom FILE_NAME 6019: XInternAtom CHARACTER_POSITION 6019: XInternAtom LINE_NUMBER 6019: XInternAtom COLUMN_NUMBER 6019: XInternAtom OWNER_OS 6019: XInternAtom HOST_NAME 6019: XInternAtom USER 6019: XInternAtom CLASS 6019: XInternAtom NAME 6019: XInternAtom SAVE_TARGETS 6019: Sending all 84 bytes 6019: Sent SelectionNotify: CLIPBOARD, target TARGETS (7513) 6019: x_stop_queuing_selection_requests 1 6019: x_handle_selection_event 6019: x_start_queuing_selection_requests 1 6019: x_handle_selection_request: selection=CLIPBOARD, target=TARGETS 6019: XInternAtom LENGTH 6019: XInternAtom FILE_NAME 6019: XInternAtom CHARACTER_POSITION 6019: XInternAtom LINE_NUMBER 6019: XInternAtom COLUMN_NUMBER 6019: XInternAtom OWNER_OS 6019: XInternAtom HOST_NAME 6019: XInternAtom USER 6019: XInternAtom CLASS 6019: XInternAtom NAME 6019: XInternAtom SAVE_TARGETS 6019: Sending all 84 bytes 6019: Sent SelectionNotify: CLIPBOARD, target TARGETS (7514) 6019: x_stop_queuing_selection_requests 1 6019: x_handle_selection_event 6019: x_handle_selection_clear 6019: x_handle_selection_event 6019: x_handle_selection_clear 6019: Get selection UTF8_STRING, type _EMACS_TMP_ 6019: Start waiting 5 secs for SelectionNotify 6019: Got event = 0 6019: Get selection UTF8_STRING, type _EMACS_TMP_ 6019: Start waiting 5 secs for SelectionNotify 6019: Got event = 0 6019: Received SelectionNotify 6019: Get selection STRING, type _EMACS_TMP_ 6019: Start waiting 5 secs for SelectionNotify 6019: Got event = 0 6019: Received SelectionNotify --8<---------------cut here---------------end--------------->8--- ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#16737: Question about wait_reading_process_output 2015-06-15 3:47 ` Stefan Monnier 2015-06-15 8:23 ` Tassilo Horn 2015-06-15 8:23 ` bug#16737: " Tassilo Horn @ 2015-06-15 14:51 ` Eli Zaretskii 2015-06-15 16:02 ` Alex Bennée 2015-06-15 16:15 ` Alex Bennée 2 siblings, 2 replies; 8+ messages in thread From: Eli Zaretskii @ 2015-06-15 14:51 UTC (permalink / raw To: Stefan Monnier; +Cc: 16737, alex.bennee > From: Stefan Monnier <monnier@iro.umontreal.ca> > Date: Sun, 14 Jun 2015 23:47:42 -0400 > Cc: emacs-devel <emacs-devel@gnu.org> > > > I've been digging into the code trying to get an idea of why bug#16737 > > fires. My question is where in wait_reading_process_output does it > > ensure the various terminal socket reads are run? > > I see noone replied yet. I can't really help you because I don't know > this code at all, but I really hope someone else will come along to > help, I will try. The terminal socket reads are run in gobble_input, which is called from detect_input_pending (via a few intermediaries). Emacs calls detect_input_pending when the pselect call in wait_reading_process_output finds that some input has arrived, and wait_reading_process_output was called with READ_KBD or WAIT_FOR_CELL arguments having values that tell it to do so. Does this answer your question? ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#16737: Question about wait_reading_process_output 2015-06-15 14:51 ` Eli Zaretskii @ 2015-06-15 16:02 ` Alex Bennée 2015-06-15 16:15 ` Alex Bennée 1 sibling, 0 replies; 8+ messages in thread From: Alex Bennée @ 2015-06-15 16:02 UTC (permalink / raw To: Eli Zaretskii; +Cc: 16737 Eli Zaretskii <eliz@gnu.org> writes: >> From: Stefan Monnier <monnier@iro.umontreal.ca> >> Date: Sun, 14 Jun 2015 23:47:42 -0400 >> Cc: emacs-devel <emacs-devel@gnu.org> >> >> > I've been digging into the code trying to get an idea of why bug#16737 >> > fires. My question is where in wait_reading_process_output does it >> > ensure the various terminal socket reads are run? >> >> I see noone replied yet. I can't really help you because I don't know >> this code at all, but I really hope someone else will come along to >> help, > > I will try. > > The terminal socket reads are run in gobble_input, which is called > from detect_input_pending (via a few intermediaries). Emacs calls > detect_input_pending when the pselect call in > wait_reading_process_output finds that some input has arrived, and > wait_reading_process_output was called with READ_KBD or WAIT_FOR_CELL > arguments having values that tell it to do so. > > Does this answer your question? Sort of. One thing that's confusing is there are two pselect() calls in the function: if ((pselect (max (max_process_desc, max_input_desc) + 1, &Atemp, #ifdef NON_BLOCKING_CONNECT (num_pending_connects > 0 ? &Ctemp : NULL), #else NULL, #endif NULL, &timeout, NULL) <= 0)) and #if defined (HAVE_NS) nfds = ns_select #elif defined (HAVE_GLIB) nfds = xg_select #else nfds = pselect #endif (max (max_process_desc, max_input_desc) + 1, &Available, (check_write ? &Writeok : 0), NULL, &timeout, NULL); Why the two? Could there be a case where one is triggering handling so that the second never gets evaluated? Am I right in thinking all incoming X messages (such as those associated with cut/paste) will come in via the X terminals gobble_input? -- Alex Bennée ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#16737: Question about wait_reading_process_output 2015-06-15 14:51 ` Eli Zaretskii 2015-06-15 16:02 ` Alex Bennée @ 2015-06-15 16:15 ` Alex Bennée 2015-06-15 18:04 ` Eli Zaretskii 1 sibling, 1 reply; 8+ messages in thread From: Alex Bennée @ 2015-06-15 16:15 UTC (permalink / raw To: Eli Zaretskii; +Cc: 16737 Eli Zaretskii <eliz@gnu.org> writes: >> From: Stefan Monnier <monnier@iro.umontreal.ca> >> Date: Sun, 14 Jun 2015 23:47:42 -0400 >> Cc: emacs-devel <emacs-devel@gnu.org> >> >> > I've been digging into the code trying to get an idea of why bug#16737 >> > fires. My question is where in wait_reading_process_output does it >> > ensure the various terminal socket reads are run? >> >> I see noone replied yet. I can't really help you because I don't know >> this code at all, but I really hope someone else will come along to >> help, > > I will try. > > The terminal socket reads are run in gobble_input, which is called > from detect_input_pending (via a few intermediaries). Emacs calls > detect_input_pending when the pselect call in > wait_reading_process_output finds that some input has arrived, and > wait_reading_process_output was called with READ_KBD or WAIT_FOR_CELL > arguments having values that tell it to do so. > > Does this answer your question? Sort of. One thing that's confusing is there are two pselect() calls in the function: if ((pselect (max (max_process_desc, max_input_desc) + 1, &Atemp, #ifdef NON_BLOCKING_CONNECT (num_pending_connects > 0 ? &Ctemp : NULL), #else NULL, #endif NULL, &timeout, NULL) <= 0)) and #if defined (HAVE_NS) nfds = ns_select #elif defined (HAVE_GLIB) nfds = xg_select #else nfds = pselect #endif (max (max_process_desc, max_input_desc) + 1, &Available, (check_write ? &Writeok : 0), NULL, &timeout, NULL); Why the two? Could there be a case where one is triggering handling so that the second never gets evaluated? Am I right in thinking all incoming X messages (such as those associated with cut/paste) will come in via the X terminals gobble_input? -- Alex Bennée ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#16737: Question about wait_reading_process_output 2015-06-15 16:15 ` Alex Bennée @ 2015-06-15 18:04 ` Eli Zaretskii 0 siblings, 0 replies; 8+ messages in thread From: Eli Zaretskii @ 2015-06-15 18:04 UTC (permalink / raw To: Alex Bennée; +Cc: 16737 > From: Alex Bennée <alex.bennee@linaro.org> > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 16737@debbugs.gnu.org > Date: Mon, 15 Jun 2015 17:15:59 +0100 > > > The terminal socket reads are run in gobble_input, which is called > > from detect_input_pending (via a few intermediaries). Emacs calls > > detect_input_pending when the pselect call in > > wait_reading_process_output finds that some input has arrived, and > > wait_reading_process_output was called with READ_KBD or WAIT_FOR_CELL > > arguments having values that tell it to do so. > > > > Does this answer your question? > > Sort of. One thing that's confusing is there are two pselect() calls in > the function: > > if ((pselect (max (max_process_desc, max_input_desc) + 1, > &Atemp, > #ifdef NON_BLOCKING_CONNECT > (num_pending_connects > 0 ? &Ctemp : NULL), > #else > NULL, > #endif > NULL, &timeout, NULL) > <= 0)) > > and > > #if defined (HAVE_NS) > nfds = ns_select > #elif defined (HAVE_GLIB) > nfds = xg_select > #else > nfds = pselect > #endif > (max (max_process_desc, max_input_desc) + 1, > &Available, > (check_write ? &Writeok : 0), > NULL, &timeout, NULL); > > Why the two? They watch different (but not orthogonal) sets of channels. > Could there be a case where one is triggering handling so > that the second never gets evaluated? There's no 'continue;' between the 2 calls to 'pselect', so I don't see how this could happen. But it's much easier to put a breakpoint at each call to 'pselect', which just announces itself and continues, or increments some counter, than reason about that humongous loop. Then you'd see very quickly if the scenario that bothers you can actually happen. > Am I right in thinking all incoming X messages (such as those associated > with cut/paste) will come in via the X terminals gobble_input? I think so, but I don't really know, sorry. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2015-06-15 18:04 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-06-05 9:49 Question about wait_reading_process_output Alex Bennée 2015-06-15 3:47 ` Stefan Monnier 2015-06-15 8:23 ` Tassilo Horn 2015-06-15 8:23 ` bug#16737: " Tassilo Horn 2015-06-15 14:51 ` Eli Zaretskii 2015-06-15 16:02 ` Alex Bennée 2015-06-15 16:15 ` Alex Bennée 2015-06-15 18:04 ` Eli Zaretskii
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.