GNU bug report logs - #33018
26.1.50; thread starvation with async processes and accept-process-output

Previous Next

Full log

Message #41 received at 33018 <at> debbugs.gnu.org (full text, mbox):

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 33018 <at> debbugs.gnu.org
Subject: Re: bug#33018: 26.1.50;
 thread starvation with async processes and accept-process-output
Date: Tue, 16 Oct 2018 15:55:28 +0100

Michael Albinus <michael.albinus <at> gmx.de> writes:

> "Basil L. Contovounesios" <contovob <at> tcd.ie> writes:
>
>> There's something about going through a complete create-join cycle more
>> than once within a non-main-thread which is triggering this behaviour.
>
> I'm not sure that it is related to threads.

It has to be, because there is never an issue when I run the same
asynchronous wget processes without threads, and with threads the hang
reliably occurs 100% of the time.

> It looks, like some of your processes do not exit properly, and then
> thread-join is blocked.

Indeed, but there is something about the interaction of Emacs threads
and subprocesses which is causing unsuccessful process termination.

Note that I am not ruling out pilot error; I simply haven't debugged
this issue any deeper yet.  The fact that no-one has yet pointed out any
obvious blunders on my part gives me more confidence that there is
indeed some ghost in the wire.

> I've modified your example, again. It runs perfectly.

Indeed, there are many subprocess-within-a-thread examples which don't
suffer from a hang, e.g. by using a different URL.  I would like to get
to the bottom of why network programs like wget/curl in particular
eventually hang, though.

Thanks,

-- 
Basil

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.