IO#dup behavior shows channels should be loosely held by IO objects
-------------------------------------------------------------------
Key: JRUBY-1957
URL: http://jira.codehaus.org/browse/JRUBY-1957
Project: JRuby
Issue Type: Bug
Reporter: Charles Oliver Nutter
Assignee: Thomas E Enebo
Fix For: JRuby 1.1
Here's part of the man page for close:
{noformat}
The close() call deletes a descriptor from the per-process object refer-
ence table. If this is the last reference to the underlying object, the
object will be deactivated. For example, on the last close of a file the
current seek pointer associated with the file is lost; on the last close
of a socket(2) associated naming information and queued data are dis-
carded; on the last close of a file holding an advisory lock the lock is
released (see further flock(2)).
{noformat}
Given this and the recently-discovered fact that IO objects returned by IO#dup
can be closed independently, it appears that IO#close should decrement a count
of references to a given channel, with the last close being the one to actually
close it. This would mimic the OS behavior described above and correct a number
of specs.
An alternative, if it is possible, would be to duplicate the channel and expect
that the underlying NIO impl will handle the reference counting. However, in my
reading of the NIO APIs there does not appear to be a way to do this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
