Francesco Nigro

@tsegismont PTAL

There's no PR, but this comment at https://github.com/vert-x3/vertx-web/issues/2603#issuecomment-2332077259 In https://github.com/vert-x3/vertx-web/issues/2603#issuecomment-2122041437 it seems the atomics are not there anymore but the atomic operations are still there...

I would make a separate RefCntResourceFile class which contains a volatile field pointing to the file to create and an atomic ref count to handle ownership and eventually the close...

> That sounds brilliant - what about allocations? @Sanne that's why I've asked to you :) If the problem of using lock(s) (can be either synchronized/Reentrant ones) within "critical code...

> Exactly what I'm getting at. The parallel-collaborative algorithm sounds great in theory, but we need to check if it fits our simple needs here. Let's say that even the...

I meant that is "good" know upfront, so it means it has predictable performance effects, which can be fixed or just accepted. I think is it very feasable to use...

PTAL @mariofusco @mkouba Note: I'm still concerned about the ordering by which these statically defined "keys" are generated, in order to happen before `Vertx` is created: any suggestion on how...

In order to enforce the ordering of key creation I should make a vertx provider which is look-up before `Vertx` instance is allocated, see doc at https://github.com/eclipse-vertx/vert.x/blob/4.5.7/src/main/java/io/vertx/core/spi/context/storage/ContextLocal.java#L25C100-L25C120

This PR will remain in draft till https://github.com/eclipse-vertx/vert.x/pull/5215 is going to be into Vertx 4.x because ATM we have no way to duplicate "optimized" keys while creating a new duplicate...

This PR is still blocked by the mentioned https://github.com/eclipse-vertx/vert.x/pull/5215 one, which should be ported to 4.x as well.