Jython closes files that are still open upon JVM shutdown with a shutdown hook. Such files are associated with their owning PySystemState, a concept which is shared with CPython and enables for multiple instances of Python running. Files are also closed when the system state itself is closed.
Only files opened from the Python domain are impacted here. Also, this is really just to support developers writing simple scripts, the expectation by most Python devs of larger systems is that they need to close files. The with-statement is getting more frequently used for this purpose. Unfortunately most of our class loader problems are seen in how PySystemState is currently implemented, although it looks the one related to automatic closing on shutdown was in fact fixed in our release. I hope we can resolve the remaining ones in our 2.6 release. - Jim On Thu, Nov 18, 2010 at 9:25 PM, jamesl <[email protected]> wrote: > Hi Charles, > > Do what your users expect which is to maintain the Ruby functionality > they rely upon. > > I see your conundrum and sympathise, I have similar things with > Redline Smalltalk. > > Sorry I can't offer a solution that is neater than detecting who > created the > channel as you have eluded to. Maybe a shutdown hook but that doesn't > appear a > long running solution. > > Rgs, James. > > On Nov 19, 3:04 pm, Charles Oliver Nutter <[email protected]> wrote: > > Hiya folks. I have a conundrum. > > > > As you know, the JDK (at least in Hotspot/OpenJDK) does not close NIO > > channels that are not closed explicitly...i.e. it does not close them > > during finalization, and from looking at the source it appears they do > > not define finalizers at all. I was under the impression that "Java" > > still finalized IO channels for bad users, but found some whispers on > > a couple forums that this behavior was changed around Java 1.5 because > > of the impact of finalizers on GC. Mark Reinhold's name was mentioned, > > and it is said that he helped make this change happen. > > > > In any case, the fact of the matter is that JVM users should not > > depend on IO channels getting closed by a finalizer. I agree with that > > decision...code that leaves IO to finalization is broken. > > > > My problem, put simply, is that C Ruby *does* close IO streams you > > don't close on your own, and users may often expect that behavior. > > > > Up through the current release version of JRuby, we mimicked that > > behavior by defining our own finalizer on our channel wrapper, and > > everyone was happy. However, it's become apparent that by doing this > > we have introduced subtle bugs over the years, such as when a channel > > we don't own enters Ruby, we wrap it, and then our finalization closes > > it prematurely. In an effort to fix that bug, I eliminated "close" > > from our finalization of those channel wrappers, which is much cleaner > > and I don't have to guess whether we own the channel or not. But now > > we're not matching Ruby behavior, and I've had about half the folks I > > polled say they'd find this change to be a major bug in JRuby. > > > > In between closing and not closing is a complicated dance of ownership > > flags, wherein I'd try to track whether JRuby initiated the channel or > > it came from outside, only closing in finalize in the former case. It > > turns my stomach a bit just to think about doing that, but I fear it > > might be my only option. > > > > So I'm stuck in a bad place. > > > > First off, can anyone confirm the reasons why Hotspot/OpenJDK doesn't > > close NIO channels via a finalize method? How about other JVM/JDK > > impls? > > > > Second...I'd like to know how you all might handle this situation. I'm > > stuck between what I believe is a technically correct solution (not > > closing in finalize) and the expectations of users who want arguably > > broken code to behave as it does in C Ruby. > > > > - Charlie > > -- > 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]<jvm-languages%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/jvm-languages?hl=en. > > -- 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.
