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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: michael.albinus <at> gmx.de, 33018 <at> debbugs.gnu.org
Subject: Re: bug#33018: 26.1.50;
 thread starvation with async processes and accept-process-output
Date: Sat, 20 Oct 2018 11:34:40 +0300

> From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
> Cc: <michael.albinus <at> gmx.de>,  <33018 <at> debbugs.gnu.org>
> Date: Wed, 17 Oct 2018 21:46:39 +0100
> 
> > I think the relevant code should be instrumented to show which thread
> > waits for what process(es).
> 
> Each thread launches a single wget process which it then waits for
> before dying, and current-thread is always eq to that thread around
> calls to accept-process-output.  Or are you talking about some other
> type of thread?

I was talking about low-level details: we set up the file-descriptor
mask passed to pselect, to tell it which descriptors to wait on.  The
call to accept-process-output is supposed to arrange for the
descriptor where the corresponding process will write to be one of
those on which the corresponding pselect will wait.  I was thinking
that perhaps we become confused and don't ask pselect called by a
thread to wait on the process which was launched by that thread.

> Either way, I'll report back when I've had a deeper look into what Emacs
> is doing, unless someone beats me to it.

Thanks.

> I'm sorry I've been talking more than doing, but university and house
> hunting will dominate my free time for the next few weeks.

No need to be sorry, we all have our lives.

Previous Next

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