harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rui Hu" <roberthu...@gmail.com>
Subject Re: [classlib][net] The old fix is not complete (was Re: [jira] Updated: (HARMONY-1117) [classlib][net] Harmony implementation of SocketImpl.getFileDescriptor() return real object, but RI return null)
Date Fri, 15 Sep 2006 05:23:02 GMT
On 9/15/06, LvJimmy´╝îJing <firepure@gmail.com> wrote:
> <snip>
> 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.

Yes, but we must initialize the fd whenever fd is not valid and needed, the
create() method is the good place to check and do it.

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

Oh, I see, you're right. But I found that in current implementation there is
a "fd = new FileDescriptor();" in PlainSocketImpl.close()  method. IMO, it
is strange. And it's the reason why your constructor solution is OK.
If we set fd to null in the close method, we must add "new FileDescriptor"
in creat method. It is more reasonable, but will cost more effort to
refactor current implementation.
So I agree with you on this occasion.  :)

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

Robert Hu
China Software Development Lab, IBM
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message