Introduce abstract native SocketChannel implementation #20
Conversation
|
This seems fine for a start. I'm trying to decide how much should be in the abstract classes and how much should be in the child classes. Having the abstract handle the basic interaction with the fd seems appropriate. With this change, NativeSocketChannel would have almost no code in it, yes? |
|
@headius Maybe I should move this abstract class into jnr-unixsocket for the first? I think its better reviewable in conjunction with unix domain socket stuff jnr/jnr-unixsocket#33 |
|
👍 |
| @@ -0,0 +1,126 @@ | |||
| /* | |||
| * Copyright (C) 2008 Wayne Meissner | |||
There was a problem hiding this comment.
@marcuslinke You probably want your name and current year here
| private int fd = -1; | ||
|
|
||
| public AbstractNativeSocketChannel(int fd) { | ||
| this(NativeSelectorProvider.getInstance(), fd); |
There was a problem hiding this comment.
Hmm, I believe this can not work without implementing NativeSelectorProvider#openSocketChannel() which currently just throws UnsupportedOperationException. At least the open() method of SocketChannel will not work, because it uses openSocketChannel() of the supplied SelectorProvider
|
Work continues here jnr/jnr-unixsocket#33 |
@headius This is the first draft. Please review. Thanks!