Open joshlf opened 6 years ago
Oh and if you want to put something in a lazy_static!
, it has to be both Send
and Sync
.
Can't you use a Collector
? It is just an Arc<Global>
: https://github.com/crossbeam-rs/crossbeam-epoch/blob/master/src/collector.rs#L23-L25. Handle
itself is threadlocal by design: https://github.com/crossbeam-rs/crossbeam-epoch/blob/master/src/collector.rs#L64-L65.
You can, but that has performance implications - every single time you want to use the GC, you have to register
a new handle, which is significantly more expensive than pinning because it involves an allocation and an atomic list insertion.
In #71, we discussed that Handle
's clone()
is not that practically useful. It seems it's relevant to this issue. At the end of the day, we need a good interface of Handle
(or SyncHandle
), which accordingly implements clone()
or not.
For data structures that want to be concurrent and only expose handles, the fact that crossbeam
Handle
s are neitherSend
norSync
is an issue. For example, in elfmalloc, we'd like to have allocator handles which are, at the very least,Sync
so that you can share them between threads by callingclone
from a new thread, but the fact thatHandle
s are notSync
has prevented us from doing that without resorting to unsafe code.The problem comes down to the fact that
Handle
s use immutable methods in thread-unsafe ways. You could imagine a handle where thepin
andis_pinned
methods were mutable, leavingclone
as the only immutable method, which would be implemented asself.collector().register()
. In fact, in order to sidestep this issue, that's exactly what I'm doing right now for elfmalloc:It would also be nice if such a handle could be
Send
, although I'm not sure how that would be done with the currentLocal
-based design.