Implement more marker traits?

[mgeier]

Should the RingBuffer be Send?
I think this might be useful.

It could probably even be Sync, even though this could only be used to get its capacity. But why not?

Could/should the Producer/Consumer be RefUnwindSafe?

What about the other structs?
Are they missing any marker traits?

[mgeier]

Since #57, the RingBuffer cannot be owned anymore, so most of this issue has become obsolete.

I'm still unsure if implementing RefUnwindSafe would make any sense.

The other structs seem to implement everything that makes sense.

[RamType0]

Send for ReadChunk and WriteChunkUninit is needed.

[RamType0]

I added it in 401a3ad

[mgeier]

Send for ReadChunk and WriteChunkUninit is needed.

I'm not sure if this is sound.

It seems that this would allow to write/read from two different threads each, which isn't allowed for SPSC. But the "chunks" have exclusive access to producer/consumer, so maybe this is OK?

If it is indeed sound, the detailed argument for that should be added as a comment.

[RamType0]

It seems that this would allow to write/read from two different threads each, which isn't allowed for SPSC. But the "chunks" have exclusive access to producer/consumer, so maybe this is OK?

Are you concerning the case having chunk and producer/consumer in different thread by sending only chunk and leave producer/consumer in original thread?

IMHO, the rust lifetime system doesn't allow it because of &mut Producer/Consumer fields in chunks.

Even if you assume that the rust lifetime system allows it, we are already able to have chunk and producer/consumer in different thread without implementing Send for chunks by sending only producer/consumer and leave chunk in original thread.

So, implementing Send for chunks doesn't make "new" problem in both assuming.

[mgeier]

I think you are right, and I agree that Send should be implemented.

I added it in 401a3ad

If you want, you can create a separate PR based on the main branch.

[RamType0]

Sorry for late response, I did it.