Currently, a switch can only be used from the domain in which it was created (and it rejects attempts to use it from another domain). It would be useful to remove this restriction. It's particularly important when implementing any kind of cache or pool that is shared between domains, since a resource allocated in one domain should be usable by the others.
Perhaps the fibers field could be made atomic, allowing any domain to prevent a switch from finishing while it's adding a resource to it. e.g. to allocate a resource:
Atomically increment fibers from a positive value.
Create the resource and attach it to the switch.
Decrement fibers.
The on_release list would need to become thread-safe too.
If changing all operations to do this is too difficult or hurts performance, it might be possible instead to add just a thread-safe transfer operation. Then other domains could open resources in their own domain and then transfer them to the cache's switch afterwards. A transfer operation would be useful even with a single domain.
Currently, a switch can only be used from the domain in which it was created (and it rejects attempts to use it from another domain). It would be useful to remove this restriction. It's particularly important when implementing any kind of cache or pool that is shared between domains, since a resource allocated in one domain should be usable by the others.
Perhaps the
fibersfield could be made atomic, allowing any domain to prevent a switch from finishing while it's adding a resource to it. e.g. to allocate a resource:fibersfrom a positive value.fibers.The
on_releaselist would need to become thread-safe too.If changing all operations to do this is too difficult or hurts performance, it might be possible instead to add just a thread-safe transfer operation. Then other domains could open resources in their own domain and then transfer them to the cache's switch afterwards. A transfer operation would be useful even with a single domain.
Requested by @art-w and @clecat.