Skip to content

Explicitly close read and write of Popen process (latex) #3309

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Oct 18, 2014

Conversation

jenshnielsen
Copy link
Member

This suppresses the final unclosed buffer/file warning in the test suite on python3.4 inside the
pgf backend.

When reading and writing from directly from stdout and stdin of the popen process they
should be explicitly closed afterwards.

These are similar to the ones fixed in #3235

@jenshnielsen
Copy link
Member Author

@pwuertz Any thoughts on this?

@pwuertz
Copy link
Contributor

pwuertz commented Jul 26, 2014

I guess I thought communicate() was supposed to close the pipes but the documentation doesn't say anything about that. It waits for end-of-file which means that the pipe was closed at the other end. So explicitly closing our end instead of letting the pipe object run out of scope seems good.

@pwuertz
Copy link
Contributor

pwuertz commented Jul 26, 2014

Out of interest: Does that warning depend on closing stdout alone or is it necessary to close stdin too? Closing latex_stdin_utf8 does not close stdin?

@jenshnielsen
Copy link
Member Author

You are right that the documentation is not clear. I think that you only need to close the stdin and stdout when you explicitly read/write to them. If you only use communicate the buffers are auto closed. The warnings only relate to read buffers so closing stdout should be sufficient.

@tacaswell tacaswell modified the milestones: v1.4.x, v1.5.x Jul 26, 2014
@WeatherGod
Copy link
Member

Does the animation module suffer the same problem?
On Jul 26, 2014 6:34 AM, "Jens H Nielsen" notifications@github.com wrote:

You are right that the documentation is not clear. I think that you only
need to close the stdin and stdout when you explicitly read/write to them.
If you only use communicate the buffers are auto closed. The warnings only
relate to read buffers so closing stdout should be sufficient.


Reply to this email directly or view it on GitHub
#3309 (comment)
.

@jenshnielsen
Copy link
Member Author

You are right that there is a potential one in the framesink used in the non file based writer. This is the only place where popen stdout/in is used in the animation module. There is another one in the file based one which is already closed explicitly.

@jenshnielsen
Copy link
Member Author

Any objections to merging this. Apart from the issues fixed by #3291 these are the last warning that I see in the test suite on the master branch.

@efiring
Copy link
Member

efiring commented Aug 31, 2014

No real objection, if it works, but the whole block looks odd: first because it doesn't seem right to close the pipes before calling communicate, and second because according to the documentation, communicate waits for the process to terminate, in which case the following call to wait is redundant.

@pwuertz
Copy link
Contributor

pwuertz commented Aug 31, 2014

Perhaps its best to remove wait() and close stdout after communicate() then.

@jenshnielsen
Copy link
Member Author

Rebased, I will clean this up later.

This avoids a warning in the test suite on python3.4. When reading
and writing from directly from stdout and stdin of the process they
should be explicitly closed afterwards.
@jenshnielsen
Copy link
Member Author

Finally got round change this to implement the suggestions above. I think this should be ready to review.

@mdboom
Copy link
Member

mdboom commented Oct 18, 2014

👍

tacaswell added a commit that referenced this pull request Oct 18, 2014
MNT : Explicitly close read and write of Popen process (latex)
@tacaswell tacaswell merged commit 52b31c0 into matplotlib:master Oct 18, 2014
@jenshnielsen jenshnielsen deleted the close_files_pgf branch October 19, 2014 17:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants