-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mutex for ServerSocketChannel#accept and Channel#write / Channel#read #109
Comments
@mschuwalow mission of this library is to provide "A small, unopinionated ZIO interface to Java NIO.". That assume that someone knows NIO which is unsafe in many ways. So don't want to add this because that is not inline in this mission statement. @quelgar @jczuchnowski WDYT? |
I'm in favour of leaving this as something the zio-nio user will have deal with in whatever way makes sense for their app. Building in a mutex could be convenient, but how sure are we that will be the ideal concurrency approach for all situations? |
So I think this is something for an "extended" module I suggested on Discord https://discordapp.com/channels/629491597070827530/629498190504132626/641323914097852476 |
Per https://docs.oracle.com/javase/7/docs/api/java/nio/channels/AsynchronousSocketChannel.html and related docs all of these are unsafe to read / write from concurrently. Currently we don't assist the user with this, and leave them on their own to respect that part of the api.
An alternative approach would be to embed a semaphores in the managed resources that we return.
This would make sure that only one concurrent read / write ever happens.
This of course will have a slight performance penalty in comparison to the current situation, but I believe it is more in line with our policy to provide functionality that makes it hard to shoot yourself in the foot with.
WDYT?
/cc @iravid @pshemass @mijicd
The text was updated successfully, but these errors were encountered: