-
Notifications
You must be signed in to change notification settings - Fork 6.2k
8351458: (ch) Move preClose to UnixDispatcher #23956
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
Conversation
👋 Welcome back alanb! A progress list of the required criteria for merging this PR into |
@AlanBateman This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 28 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
@AlanBateman The following label will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see any problems. This looks like a nice cleanup.
*/ | ||
final void preClose(FileDescriptor fd, long reader, long writer) throws IOException { | ||
if (NativeThread.isVirtualThread(reader) || NativeThread.isVirtualThread(writer)) { | ||
int fdVal = JIOFDA.get(fd); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hello Alan, previously, in the case of DatagramChannelImpl
, the fdVal
was a final
that was determined when the channel was constructed. Now, that fdVal
gets determined as and when needed and I see that FileDescriptor
allows this underlying value to be changed/reset. Is there anything practical to consider here in context of a fdVal
that has been reset in the FileDescriptor
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
repairSocket doesn't change fd/fdVal, instead they will be connected to a new socket if the method succeeds (or the old socket if it fails).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was the FileDescriptor.set(int fd)
method which I had in mind. But I now looked at its references and I see that there aren't any in the code paths that this PR deals with. So I believe the proposed change looks good.
* dup'ed to a special fd and the thread signalled so that the syscall fails with EINTR. | ||
*/ | ||
final void preClose(FileDescriptor fd, long reader, long writer) throws IOException { | ||
if (NativeThread.isVirtualThread(reader) || NativeThread.isVirtualThread(writer)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There used to be a if (reader != 0 || writer != 0) {...}
check before doing any of this pre-close work, in DatagramChannelImpl
. Is that no longer needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There used to be a if (reader != 0 || writer != 0) {...} check before doing any of this pre-close work, in DatagramChannelImpl. Is that no longer needed?
Looking at the implementation of NativeThread.isNativeThread()
and NativeThread.isVirtualThread()
, it already implicitly takes into account the != 0
check, so I guess the previous explicit checks before calling those methods was redundant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, there are a several places where check for != 0 would be redundant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes look good to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, on Unix, the fd needs to be dup'ed and the native thread signalled. On Windows, the dup() operation does not happen, but the threads were being signalled previously, but not any more. Was that redundant previously?
There's never been any signalling of threads on Windows, NativeThread::isNativeThread always returns false. So no change on Windows. |
Thanks for the reviews/comments. |
/integrate |
Going to push as commit 0de2cdd.
Your commit was automatically rebased without conflicts. |
@AlanBateman Pushed as commit 0de2cdd. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
/backport jdk21u-dev |
@shruacha1234 Could not automatically backport
Please fetch the appropriate branch/commit and manually resolve these conflicts by using the following commands in your personal fork of openjdk/jdk21u-dev. Note: these commands are just some suggestions and you can use other equivalent commands you know.
Once you have resolved the conflicts as explained above continue with creating a pull request towards the openjdk/jdk21u-dev with the title Below you can find a suggestion for the pull request body:
|
Network channels in blocking mode, and the NIO based SocketImpl, have to deal with async close when there are threads blocked on the channel. Virtual threads blocked on the channel need to be unparked. On Unix systems, platform threads blocked on the channel require the file descriptor to be dup'ed to a special file descriptor and the threads signalled.
There is a bit of duplication in the implementation of the 5 channels, and in the SocketImpl. In addition, there is discussion on net-dev about an issue in AIX that will require allowing for signals to be queued (the current implementation does not require OS to support queuing of signals).
We refactor this code so that the "prepare for close" is in one place, UnixDispatcher.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/23956/head:pull/23956
$ git checkout pull/23956
Update a local copy of the PR:
$ git checkout pull/23956
$ git pull https://git.openjdk.org/jdk.git pull/23956/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 23956
View PR using the GUI difftool:
$ git pr show -t 23956
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/23956.diff
Using Webrev
Link to Webrev Comment