Behavior of DatagramChannel vs ByteBuffers bound to MemorySessions
Cleber Muramoto
cleber.muramoto at gmail.com
Sat Jun 8 15:55:12 UTC 2024
@Alan,
Yes, Arenas can be closed at any time. Still, from my understanding, this
implicit restriction should only be imposed in code that does not invoke
JavaNioAccess::acquireSession explicitly, like in NioSocketImpl or
SocketChannelImpl.
Regarding safety issues, do you mean the possibility of the NIO layer
accessing an invalid address?
In the case of interleaving JavaNioAccess::acquireSession & Arena::close, I
think there are only two possible outcomes:
A)Arena is closed in Thread A, then Writer Thread B fails with
IllegalStateException
B)Writer Thread B acquires the session, then Thread A fails with
IllegalStateException
I don't think it is possible to reach a state where the NIO layer sees an
invalid (freed) address (unless of course the user code messes with jdk
internals by calling MemorySession::release0 explicitly in other thread).
As for "APIs that do asynchronous IO", are you refering to JDK internals
where the user has no control over the thread performing the write
operation? This is supported by, e.g., by AsynchronousSocketChannel
---
var buffer =
Arena.ofShared().allocate(1024).asByteBuffer().putInt(42).flip();
var q = new LinkedBlockingQueue<>();
var asc = AsynchronousSocketChannel.open();
asc.connect(new InetSocketAddress("openjdk.org", 443)).get();
asc.write(buffer, null, new CompletionHandler<Integer, Void>() {
public void completed(Integer result, Void attachment) {
q.offer(result);
}
public void failed(Throwable exc, Void attachment) {
exc.printStackTrace();
q.offer(exc);
}
});
System.out.println(q.take()); // 4
---
Regards
On Sat, Jun 8, 2024 at 5:22 AM Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 07/06/2024 18:00, Cleber Muramoto wrote:
> > Hello, I'd like to understand why a disconnected DatagramChannel does
> > not support direct buffers derived from MemorySegments created from
> > shared Arenas.
> >
> >
> A shared Arena can be closed at any time. There are safety guarantees
> that go along with that are problematic when doing I/O with byte buffers
> that are backed by a memory segment allocated. For APIs that do
> synchronous I/O then it may be possible to remove this restriction at
> some point. For APIs that do asynchronous I/O (as in initiate an I/O op
> on one thread, complete on another) then it is a harder problem.
>
> -Alan
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20240608/11006897/attachment.htm>
More information about the nio-dev
mailing list