2006/9/14, Rui Hu <[EMAIL PROTECTED]>:
On 9/14/06, Jimmy, Jing Lv <[EMAIL PROTECTED]> wrote: > > Andrew Zhang wrote: > > I don't think the fix is complete. The patch only fixed reported bug, > but > > introduces new severe bugs. > > > > Because fd would never be initialized after applying the patch. Running > all > > tests would also fail with crash. > > > > Yes, fd without initialized may cause a tragedy, all network functions > relay on this. > > > After deleting initialization code in SocketImpl.java, we have to > > initialize > > SocketImpl.fd elsewhere. I suggest add the code into > > PlainSocketImpl.createmethod. Am I right? > > > > I believe this may be correct. Or we can add a constructor in > PlainSocketImpl, initial fd there. IMHO, Andrew's suggestion is better. The fd should be initialized not only when constructor is called, but also in some other occasions. e.g. PlainSocketImpl.create is called by checkClosedAndCreate(boolean) of Socket/ServerSocket class, and widely called by other methods(bind,connect...etc) indirectly, when a Socket/ServerSocket try to check status(open/closed) and re-create its netimpl.
Ah yes, I remember this, this caused a bug in interaction with NIO channels :) However, fd-initialization and socket-creation are two different things. fd-initialization means only "new FileDescriptor()", but create socket means create a socket in native code. fd-initialization in Constructor is at least good: 1. fix the bug, but not break current correct logic at all, so it may pass all the test 2. may not new another fd, so save a little memory ;) However I have no objection on Andrew's idea :) <snip> -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM
