On Fri, Nov 19, 2010 at 12:54 PM, Charles Oliver Nutter <[email protected]> wrote: > On Thu, Nov 18, 2010 at 11:02 PM, John Rose <[email protected]> wrote: >> Suggestion: Make the "close" behavior optional, per wrapper. >> Only set the "mustClose" bit on channels created via Ruby APIs. > > Yes, unfortunately that seems to be the only option, since pretty much > everybody believes we need to behave like C Ruby wrt finalization of > IO objects (even while agreeing that leaving those IO streams to > finalization is bad form).
If there's a Ruby method for retrieving the underlying Java object, make sure that method turns off the mustClose bit as well, or things will get funky if the Java object outlives the Ruby object. Scsh, the Scheme shell, plays similar tricks with Scheme ports and Unix file descriptors, only it goes further. If the user program tries to explicitly allocate a file descriptor (with dup2(), for example), scsh checks to see if it's already in use for some existing Scheme port. If so, it switches the Scheme port to a new file descriptor using dup(), freeing it up for the program's use. Fortunately, this isn't necessary in Java, where there is no way for user code to mess with the internals of Java streams. -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
