GNU bug report logs - #13400
23.4; overlapping process filter calls

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: hendrik <at> askra.de, 13400 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#13400: 23.4; overlapping process filter calls
Date: Thu, 08 Aug 2019 16:36:20 +0300

> From: Noam Postavsky <npostavs <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  13400 <at> debbugs.gnu.org,  hendrik <at> askra.de
> Date: Wed, 07 Aug 2019 23:37:29 -0400
> 
> > So the default should be to prevent it, with maybe some way to override
> > it to cater to the exceptional case where recursive invocation
> > is to be allowed.
> >
> > I think we could do that by setting a property on process object during
> > filter invocation to postpone further filter invocations, and then the
> > process filter could locally unset this property if it wants to allow
> > recursive invocations.
> 
> Yeah, I suppose that would probably be better.  Although then we have
> some potential weird edge cases like what happens when when changing the
> property during a recursive invocation.

Hmm... I'm not sure I understand what would this mean in practice.
Suppose a process filter invokes some blocking API, which then calls
wait_reading_process_output, and 'pselect' tells us that same process
can be read from again.  How will we avoid calling the filter
recursively in this case, and what will we do instead of calling it?

Previous Next

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