Investigate possibility to integrate debug module with BlockHound #1031
Comments
|
FYI this is how Reactor itself now integrates with BlockHound: (There is no code for Reactor 3.3.x in the BlockHound itself, and reactor-core controls how it should be integrated) |
|
@bsideup Thanks. We'll get back to it after the |
|
FYI BlockHound 1.0.0.RELEASE is out (on Maven Central): |
This change adds a new API to mark threads as "dynamic",
which means that the blocking check should call `threadPredicate
once again before reporting the blocking call.
Example usage:
```java
b.addDynamicThreadPredicate(DynamicThread.class::isInstance);
b.nonBlockingThreadPredicate(p -> p.or(thread -> {
return thread instanceof DynamicThread && ((DynamicThread) thread).isNonBlocking;
}));
```
where `DynamicThread#isNonBlocking` is a field that reflects the current "mode".
It helps frameworks like Kotlin's Coroutines where a thread may change from blocking
to non-blocking dynamically (see Kotlin/kotlinx.coroutines#1031)
|
I just merged the support for dynamic predicates that should unblock Kotlin from progressing. I will appreciate if you give it a try before the release and let us know if there is anything else that blocks you from progressing. |
https://github.com/reactor/BlockHound/blob/master/docs/custom_integrations.md
We should investigate whether we can opt-in for block hound by default without explicit user actions (besides enabling debugger) or a least to provide a simple switch "detect blocking calls" in the debugger.
The text was updated successfully, but these errors were encountered: