This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gvanrossum
Recipients David.Edelsohn, db3l, gvanrossum, larry, ncoghlan, neologix, pitrou, python-dev, sbt, skrah
Date 2013-10-20.19:01:41
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAP7+vJKw1=Q7r8v4BwmCSu6Xy0POKaV4rCzkCecxoSE0Qg_zgQ@mail.gmail.com>
In-reply-to <1382290630.75.0.873899733542.issue19293@psf.upfronthosting.co.za>
Content
No, there's a use case for reading after the child exited, if there is a
grandchild still writing.

--Guido van Rossum (sent from Android phone)
On Oct 20, 2013 10:37 AM, "Richard Oudkerk" <report@bugs.python.org> wrote:

>
> Richard Oudkerk added the comment:
>
> > I guess we'll have to write platform-dependent code and make this an
> > optional feature. (Essentially, on platforms like AIX, for a
> > write-pipe, connection_lost() won't be called unless you try to write
> > some more bytes to it.)
>
> If we are not capturing stdout/stderr then we could "leak" the write end
> of a pipe to the child.  When the read end becomes readable we can call the
> process protocol's connection_lost().
>
> Or we could just call connection_lost() when reaping the pid.
>
> ----------
> nosy: +sbt
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue19293>
> _______________________________________
>
History
Date User Action Args
2013-10-20 19:01:42gvanrossumsetrecipients: + gvanrossum, db3l, ncoghlan, pitrou, larry, skrah, neologix, python-dev, sbt, David.Edelsohn
2013-10-20 19:01:42gvanrossumlinkissue19293 messages
2013-10-20 19:01:41gvanrossumcreate