From: Mike Pomraning <redmine@...>
Date: 2009-10-23T07:05:23+09:00
Subject: [ruby-core:26242] [Bug #2250] IO::for_fd() objects' finalization dangerously closes underlying fds

Issue #2250 has been updated by Mike Pomraning.


In comment 2 Nobuyoshi Nakada writes:
> This is a patch to add :autoclose option to IO.for_fd

Thanks!  IIUC, your patch requires one to explicitly set
:autoclose => false to avoid this behavior.  However, I'd
argue that no autoclose ought to be the default behavior.

IMHO, if you know enough about fds to dress one up as an
IO, you know enough to judge whether Ruby should close it
for you.  Ruby can never know this a priori, and in most
cases I can think of, it isn't ever desired.

Indeed, a 2002 commit message suggests that not closing
should be the default:

  | Revision 2312 matz, 04/01/2002 01:39 AM
  |
  |  * re.c (match_setter): it's OK to assign nil to $~.
  |  * io.c (rb_io_fptr_cleanup): do not close IO created by for_fd().
  |  * io.c (rb_io_initialize): mark IO created by for_fd
  |  * ext/socket/socket.c (bsock_s_for_fd): ditto.


> Basically, such extension libraries should expose IO
> instances, but not file descriptors.

Where practicable, yes.  Respectfully and UIMS, however,
I think this asks too much of ext library authors.

Either they must wait for and explicitly use your
autoclose feature, or must manage their own IO object
references -- and the binding authors themselves may
only have a "naked" fd to play with, may not know when
the underlying library chooses to call close(), etc.

Regards,
Mike
----------------------------------------
http://redmine.ruby-lang.org/issues/show/2250

----------------------------------------
http://redmine.ruby-lang.org