On Fri, 30 Jun 2006, Charles O Nutter defenestrated me: > > I'll have a look. A few comments inline below. > > On 6/29/06, Thomas E Enebo <[EMAIL PROTECTED]> wrote: > > On Thu, 29 Jun 2006, Charles O Nutter defenestrated me: > > > > Whee! > I needed to do a surprising additional number of things to > get rails silence_stderr working with this patch. Here is a break- > down: > 1. reopen with string as first arg should retain permissions/modes > of IO it is reopening. I believe this has to be right. > > The reopen thing worried me too since I knew some of that was going on > with the /dev/null thing.
Setting modes to "r" when no secnd arg provided when reopens first arg was a string was just plain wrong. This fix should be safe. > 2. dup should retain dup'd objects permissions/modes. This also > seems like a for sure thing. > > Agreed. > > 3. reopen needed same /dev/null check that RubyFile has in reopen. > As hacky as hacky gets. > > Hacky but temporary. Another way to fix this might be to include "win" > in the platform when running on windows, and that might also just make > it work...but I don't know with what side effects. Yeah, I would be worried about what other stuff may get turned on by doing that. Another way to mitigate the hack is to System.getProperty and only do the hack on windows. I am not sure it would make that much difference though. > 4. IOHandlerUnseekable now refuses to close System.out and > System.err. > This is also a hack. The solution involves much too much stuff > to be safe right now. Really a io.dup should clone the > underlying > IOHandler. If multiple IO's point to same underlying stream > then a close should not really close the underlying stream. > I believe this is consistent with C FILE* and friends (C Ruby > semantics I think rely on FILE* and friends)? > > Since IO streams in Java close when you tell them to we'll need to do > some kind of reference counting to know when the last IOHandler lets > go. We'll probably need a better solution long-term, but it may be ok > for now. I think we may need to reference count streams used in IOHandlers, but yeah something like that. When we dup we are supposed to make something which has a new fileno, but has same position offset. So we would end up with two IOHandlerUnseekables that point to the same underlying stream. From a C perspective IOHandlers are FILE structs and streams are file descriptors. > Please look this over. I would like to include this for 0.9.0 > since it makes Rails commands that perform command checks work > without needing to patch Rails. > > I don't like patching but I also don't like last minute changes like > this. Thankfully this should only affect opening /dev/null (right?) > and so if it's busted we just tell people to patch anyway. These changes really will only affect reopen consumers. Anyone opening /dev/null that expect to do real file IO is nuts :) I looked at 1.8 reopen users in the standard library and reopen is used for two things: 1. Redirecting output to somewhere for a little bit (like /dev/null or a log file) 2. Manipulating IO after a fork Number 2 is immediately not a concern since we do not support fork. Number 1 is what these fixes supposedly help. There are not that many either, the most important being webrick. I can tell that is working (though it is still outputting requests to stdout which I think should be in the log file -- so even with these fixes that did not straighten out). -Tom -- + http://www.tc.umn.edu/~enebo +---- mailto:[EMAIL PROTECTED] ----+ | Thomas E Enebo, Protagonist | "Luck favors the prepared | | | mind." -Louis Pasteur | Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Jruby-devel mailing list Jruby-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jruby-devel
