-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
5 changed files
with
173 additions
and
2 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,5 +1,5 @@ | ||
msquic | ||
{ | ||
global: MsQuicOpen; MsQuicClose; | ||
global: MsQuicOpen; MsQuicClose; MsQuicJavaInit; MsQuicGetJNIEnv; | ||
local: *; | ||
}; |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
3e87aa1
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.
@wkgcass I noticed you making these changes and I was wondering what your end goal was. Do you plan to try to merge any of this back into msquic mainline? cc @ThadHouse
3e87aa1
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.
@nibanks Hi, MsQuic is great work. I would like to use MsQuic in Java through JNI, and use it in my networking toolkit called vproxy.
This commit basically adds two apis: one allow JNI code to pass
JavaVM*
into the lib, another retrievingJNIEnv*
for the current thread, which will be used in thelistener/connection/stream
callbacks. And when threads launch, attach the spawn threads to JVM and store theJNIEnv*
to threadlocal.This commit is a little tricky and seems only apply for this specific usage, so I'm afraid this might not be able to merge to the origin.
However this commit is kept small and easy to maintain.
3e87aa1
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'm believe a more general way of implementing this is to add a callback function which triggers when thread starts/stops.
And would be better to have a thread related context be tracked and passed to the user callbacks to reduce the cost of using thread local variables.
3e87aa1
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 first part I'm looking into, at least for the specific threads that enter Java. This only changes a small number of lines to do so.
The 2nd part is actually a much bigger change. Its something I can see the usability in wanting it, but doing so is fairly invasive, especially because a connection/listener/stream isn't held to a specific worker over its lifetime. Thread locals for that are likely easier and cleaner, especially with C having built in thread locals nowadays.
3e87aa1
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.
My preference to fix the first part is something like this. Then the Java code would define something like
platform_linux_java.c
, which would just implementQuicThreadCustomStart
to do what it needs. Then a new CMake arg/option would be for "Java Mode" which would defineQUIC_USE_CUSTOM_THREAD_CONTEXT
and include the newplatform_linux_java.c
file. This would allow good separation (IMO) between the generic and Java-specific code. I don't want to expose this via the official MsQuic API because this is still platform specific logic and not application layer, again, IMO.As far as the second, like @ThadHouse said, that would be a MUCH bigger change, and I'd really try to avoid that if at all possible. We'd have to have proof that the change was absolutely necessary before I'd consider it.
3e87aa1
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.
Yes, I can see that the second part is nearly impossible to implement for the current code base, and using a thread local variable solves most problems and the thread local performance cost is acceptable.
3e87aa1
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.
Thanks for your example code. @nibanks
I'm wondering if we can make the
QuicThreadCustomStart
a standard api in this way:1. define thread related parameters in QUIC_REGISTRATION_CONFIG
2. user code
Users can say:
I haven't read the
Registration
code (I was reading theListeners/Connections/Streams
), so I'm not sure whether the code snippets make sense.I'll read the related code to verify my idea today or tomorrow.
3e87aa1
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.
Yes, that's possible and pretty much what @ThadHouse has in microsoft/msquic#1126. I am hesitant to go that route though, because it isn't something that most apps would actually need... BTW, instead of having this discussion here, @wkgcass would you mind starting a discussion about this here: https://github.com/microsoft/msquic/discussions?
3e87aa1
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.
Maybe just discuss the related topics in the PR ?
3e87aa1
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've talked with my coworkers some more and we'd be interested in working with you and merging your work for Java support into mainline MsQuic. Would you be interested in pushing these changes back (with some changes most likely)? cc @anrossi & @ThadHouse
3e87aa1
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'm willing to. I'm sure a lot of modifications should be made... Any suggestion?
3e87aa1
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've opened microsoft/msquic#1141 to track adding Java support. We can move our discussion there. My goal would be to figure out how we can break what you have up into separate changes that are easier to design and code review. To that effect, I've created microsoft/msquic#1142. We can discuss more on either the issue or the PR. Thanks!