From aaef199db2cabb19b8d2b047ce80affd5bd29789 Mon Sep 17 00:00:00 2001 From: He-Pin Date: Sun, 19 Jan 2025 09:10:56 +0800 Subject: [PATCH] chore: Add new line to the doc --- docs/pages/1 - Cask - a Scala HTTP micro-framework.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/pages/1 - Cask - a Scala HTTP micro-framework.md b/docs/pages/1 - Cask - a Scala HTTP micro-framework.md index 507e615c99..1f1dd6395c 100644 --- a/docs/pages/1 - Cask - a Scala HTTP micro-framework.md +++ b/docs/pages/1 - Cask - a Scala HTTP micro-framework.md @@ -473,11 +473,13 @@ Cask can support using Virtual Threads to handle the request out of the box, you 4. tweak the underlying carrier threads with `-Djdk.virtualThreadScheduler.parallelism`, `jdk.virtualThreadScheduler.maxPoolSize` and `jdk.unparker.maxPoolSize`. **Advanced Features**: + 1. You can change the default scheduler of the carrier threads with `cask.internal.Util.createVirtualThreadExecutor` method, but keep in mind, that's not officially supported by JDK for now. 2. You can supply your own `Executor` by override the `handlerExecutor()` method in your `cask.Main` object, which will be called only once when the server starts. 3. You can use `jdk.internal.misc.Blocker`'s `begin` and `end` methods to help the `ForkJoinPool` when needed. **NOTE**: + 1. If your code is CPU-bound, you should not use virtual threads, because it will not improve the performance, but will increase the overhead. 2. A common deadlock can happen when both a virtual thread and a platform thread try to load the same class, but there is no carrier thread available to execute the virtual thread, which will lead to a deadlock, make sure `jdk.virtualThreadScheduler.maxPoolSize` is large enough to avoid it. 3. Virtual thread does some kind of `rescheduling` which may lead to higher latency when the task is actually cpu bound.