Open Packsolite opened 6 months ago
Thanks, for the report, I'll take a look this weekend. And try to set up a test to automate this check.
Thanks, for the report, I'll take a look this weekend. And try to set up a test to automate this check.
Not quite sure how you would automate the detection of virtual thread pinning in a test without hacky hooks. Can you recommend any tool?
I'm just capturing System.out
First set of core fixes https://github.com/square/okhttp/pull/8290
First set of core fixes #8290
Would it be possible to provide a build of the latest commit? You can call me lazy, but i can't build it myself due to not having android setup on my machine. Possibly providing a jar for every branch via github actions? Thanks alot!
Just a note for others suffering from this same issue; this is still present in 5.0.0-alpha.14
, I assume this is because https://github.com/square/okhttp/pull/8290 got reverted via https://github.com/square/okhttp/pull/8367, and https://github.com/square/okhttp/pull/8371 isn't part of an alpha release build yet.
https://github.com/square/okhttp/blob/bad2ebc296c8094370cf94291f571dd618ba7400/okhttp/src/main/kotlin/okhttp3/internal/connection/RealCall.kt#L376
This line causes virtual thread pinning in the latest alpha (5.0.0-alpha.12). Reason is the use of a ReentrantLock (in TaskQueue.schedule) inside a synchronized block when using a connection pool with a
maxIdleConnection
.Log output with JVM argument
-Djdk.tracePinnedThreads=full
:How to reproduce
Use the blocking OkHttpClient api from a virtual thread like this:
Run the code with
-Djdk.tracePinnedThreads=full