From: "Basil L. Contovounesios" <contovob@tcd.ie>
To: 33018@debbugs.gnu.org
Subject: bug#33018: 26.1.50; thread starvation with async processes and accept-process-output
Date: Thu, 11 Oct 2018 15:57:50 +0100 [thread overview]
Message-ID: <87r2gwbmma.fsf@tcd.ie> (raw)
[-- Attachment #1: test.el --]
[-- Type: application/emacs-lisp, Size: 1892 bytes --]
[-- Attachment #2: Type: text/plain, Size: 3547 bytes --]
I attach a sample program test.el whose central function, test-slave,
invokes wget asynchronously before waiting for the process to exit.
The issue I'm facing is that running test-slave twice in succession,
each time in a new thread, causes accept-process-output to hang with no
output (unless a timeout argument is given, in which case the function
returns nil) the second time around.
When this happens, the process sentinel is never called, which is why
I'm assuming accept-process-output is indeed "hanging" in some sense and
it's not just that the process has already exited and so has no further
output.
I could very well be doing or assuming something incorrectly, but what
baffles me is that the "hang" does not occur either when Emacs is run
non-interactively, or when "https://en.wikipedia.org/wiki/Emacs" is
replaced with "https://www.gnu.org/software/emacs/", or when test-slave
is run in the current thread (and not in make-thread).
Since I can reliably reproduce this on both an optimised build of master
and a non-optimised build of emacs-26, I hope to be able to provide
further insights using gdb as time allows. Please let me know if there
are any specific details/output you would like me to provide. As a
relatively inexperienced gdb user I welcome any tips and tricks for
debugging threads and processes.
Here are some ways test.el can be run to illustrate the issue:
# All five processes exit successfully.
emacs -batch -l test.el -f test-no-threads
# All five processes (and threads) exit successfully.
emacs -batch -l test.el -f test-threads
# All five processes exit successfully.
emacs -Q -l test.el -f test-no-threads
# First process and thread exit successfully,
# but accept-process-output starts timing out in second thread.
# Warning: may leave empty wget-log files lying around.
emacs -Q -l test.el -f test-threads
Details of the two Emacs versions I'm using follow:
In GNU Emacs 26.1.50 (build 2, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
of 2018-10-11 built on thunk
Repository revision: a7ebc6bf633bd3849ccab032dad6b1fd31b1ef43
Windowing system distributor 'The X.Org Foundation', version 11.0.12001000
System Description: Debian GNU/Linux testing (buster)
Configured using:
'configure 'CC=ccache gcc' 'CFLAGS=-O0 -g3 -ggdb -gdwarf-4 -pipe'
--config-cache --prefix=/home/blc/.local --program-suffix=26
--enable-checking=yes,glyphs --enable-check-lisp-object-type
--with-mailutils --with-x-toolkit=lucid --with-modules
--with-file-notification=yes --with-x'
Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS
GLIB NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT
ZLIB TOOLKIT_SCROLL_BARS LUCID X11 XDBE XIM MODULES THREADS LIBSYSTEMD
LCMS2
In GNU Emacs 27.0.50 (build 21, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
of 2018-10-11 built on thunk
Repository revision: 5bd8cfc14d4b0c78c07e65a583f42a10c4cbc06d
Windowing system distributor 'The X.Org Foundation', version 11.0.12001000
System Description: Debian GNU/Linux buster/sid
Configured using:
'configure --config-cache --prefix=/home/blc/.local --with-mailutils
--with-x-toolkit=lucid --with-modules --with-file-notification=yes
--with-x 'CC=ccache gcc' 'CFLAGS=-O2 -march=native -pipe''
Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS
GLIB NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT
ZLIB TOOLKIT_SCROLL_BARS LUCID X11 XDBE XIM MODULES THREADS LIBSYSTEMD
JSON LCMS2 GMP
Thanks,
--
Basil
next reply other threads:[~2018-10-11 14:57 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-11 14:57 Basil L. Contovounesios [this message]
2018-10-12 8:07 ` bug#33018: 26.1.50; thread starvation with async processes and accept-process-output Eli Zaretskii
2018-10-14 15:00 ` Basil L. Contovounesios
2018-10-14 15:17 ` Eli Zaretskii
2018-10-14 15:36 ` Basil L. Contovounesios
2018-10-12 12:02 ` Michael Albinus
2018-10-12 12:43 ` Eli Zaretskii
2018-10-12 12:49 ` Michael Albinus
2018-10-14 15:17 ` Basil L. Contovounesios
2018-10-15 8:02 ` Michael Albinus
2018-10-16 1:15 ` Basil L. Contovounesios
2018-10-16 13:54 ` Michael Albinus
2018-10-16 14:55 ` Basil L. Contovounesios
2018-10-16 14:58 ` Eli Zaretskii
2018-10-17 17:37 ` Basil L. Contovounesios
2018-10-17 17:56 ` Eli Zaretskii
2018-10-17 18:05 ` Basil L. Contovounesios
2018-10-17 18:20 ` Eli Zaretskii
2018-10-17 18:25 ` Eli Zaretskii
2018-10-17 20:46 ` Basil L. Contovounesios
2018-10-20 8:34 ` Eli Zaretskii
2018-10-17 20:02 ` Basil L. Contovounesios
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=87r2gwbmma.fsf@tcd.ie \
--to=contovob@tcd.ie \
--cc=33018@debbugs.gnu.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.