Skip to content
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

Unix.shutdown_connection should be commented with more details #6183

Closed
vicuna opened this issue Sep 17, 2013 · 2 comments
Closed

Unix.shutdown_connection should be commented with more details #6183

vicuna opened this issue Sep 17, 2013 · 2 comments

Comments

@vicuna
Copy link

vicuna commented Sep 17, 2013

Original bug ID: 6183
Reporter: furuse
Assigned to: @xclerc
Status: closed (set by @xavierleroy on 2015-12-11T18:25:38Z)
Resolution: fixed
Priority: normal
Severity: minor
Version: 4.01.0
Fixed in version: 4.01.1+dev
Category: standard library
Tags: patch, junior_job
Monitored by: @gasche @avsm

Bug description

As indicated in this blog post http://tategakibunko.hatenablog.com/entry/20130703/1372824611 , there are common misuses of Unix.shutdown_connection: in_channels are shutdown but never closed, and this results into FD leaks.

I quickly grepped my OPAM build directories and found two uses of Unix.shutdown_connection, one from lalbgtk and another from ocamlnet, which are such examples.

This should be because users read unix.mli and misunderstand that open_connection is a creator of channels and then shutdown_connection should be the final consumer.

One line of comment to tell that in_channel still need to be closed after Unix.shutdown_connection should help the situation.

File attachments

@vicuna
Copy link
Author

vicuna commented Sep 18, 2013

Comment author: @avsm

Doc patch added.

@vicuna
Copy link
Author

vicuna commented Jan 23, 2014

Comment author: @xclerc

Patch applied in both trunk (revision 14419) and 4.01 (revision 14418) branches.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant