I think in practice it has to do with some libs (eg jdbc drivers) that would be relying on synchronized. If the performance with vthreads was much worse for some cases it would be a bit of failure
> I think in practice it has to do with some libs (eg jdbc drivers) that would be relying on synchronized.
Those usually have company / community backing that gets it fixed. The irony is you patch the ORM and you patch the JDBC driver only to realize the database pooling library in-between is the 1 that's broken and the author refuses to fix it.
Switching `synchronized` for `ReentrantLock` is possible in principle, but it makes the code harder to read and opens the door to subtle concurrency bugs.
Library authors really don't want this kind of code churn for an issue that is not their fault, not their responsibility to solve, and that will get a bugfix before long that maybe even qualifies for a backport to LTS 21.
re-thc|11 months ago
Those usually have company / community backing that gets it fixed. The irony is you patch the ORM and you patch the JDBC driver only to realize the database pooling library in-between is the 1 that's broken and the author refuses to fix it.
samus|11 months ago
Library authors really don't want this kind of code churn for an issue that is not their fault, not their responsibility to solve, and that will get a bugfix before long that maybe even qualifies for a backport to LTS 21.