Eliza Weisman

Unfortunately, the sharding scheme this library uses relies on assigning an ID to each thread spawned by a program. This is implemented using a thread-local variable: https://github.com/hawkw/sharded-slab/blob/8ebe120fd28b3a463932bbf0728e2baf5a558840/src/tid.rs#L40-L42 Because threads are...

I think the `Entry` type can probably be `Send`. Off the top of my head, I certainly can't think of any reason why it can't be.

In theory, I would be happy to accept a pull request adding the capability to serialize a `Slab` as though it were a vector. However, this is somewhat complex: serializing...

> I checked the commit history, but I could not find serde support. Where was this added? I closed this issue because, as I stated in my previous comment, I...

Again, because it is not possible to iterate over a `Slab` through an `&`-reference, the `serde::Serialize` implementation would have to be for a `&mut Slab`, rather than for `Slab`. This...

It would require exclusive mutable access to the slab, similar to the existing [`Slab::unique_iter`](https://docs.rs/sharded-slab/latest/sharded_slab/struct.Slab.html#method.unique_iter) method. But, we could potentially provide something like that.

Can you share what `RUSTFLAGS` you've set and what features are enabled?

Well, that's certainly strange!

> I took a couple of drastic changes: > > * first of all the signature changes of `Service`. But that is obvious as it's the entire idea of this...

The fact that there is (currently) no way to introduce bounds like `Send`, `Sync`, `'static`, or `Unpin` on the futures generated by async trait functions is a significant limitation of...