When upgrading my project from 0.14 to 0.16, I had to replace my linear fifo by another thread-safe container.
Io.Queue is doing the job very well. So well that I’m wondering what is the purpose of Deque ? It seems Io.Queue can do everything that Deque does, with the same speed and roughly the same interface. With Io, Io.Queue can work in both multi-threaded or single threaded environnements. In what cases should I use Deque ?
Another question: Is there a reason Io.Queue and Deque don’t have a Reader/Writer ? It would be very useful to stream from/to those containers directly without having to extract the data (take/peek/readSlice).
I’ve tried to simply use a fixed buffer (Writer.fixed and Reader.fixed). It works quite well on a single thread, but I’m don’t think this approach is thread-safe. If so, I could simply use a fixed buffer instead of a Io.Queue. Is it thread-safe ?
Io.Queue integrates with Io and is concurrency safe. It will not work with raw threads!
Deque does not integrate with Io and is also not thread safe.
If you find them to have similar performance than they are likely not the bottle neck of whatever you are doing.
Deque should have much less overhead.
The latter paragraph explains why Io.Queue doesn’t have this. Reader/Writer are not concurrency safe.
Reader, Writer are abstractions over byte streams. Whereas these queues are generic, buffered, FIFO’s. They are only comparable in that they all have ring buffers, but otherwise they have very different use cases.
The use case for them having a Reader or Writer seems niche, and cause for rethinking design decisions.
I’m using my Io.Queue in a task spawned by Io.async() or Io.concurrent(). So it works as intended. For my information, do you mean I can’t use it inside a task spawned by Thread.spawn() ? In that case, what thread-safe container should I use ?
If you find them to have similar performance than they are likely not the bottle neck of whatever you are doing.
For sure, these queues are not the bottleneck, they have to handle like 3 ko/s.
Reader, Writer are abstractions over byte streams. Whereas these queues are generic, buffered, FIFO’s. They are only comparable in that they all have ring buffers, but otherwise they have very different use cases.
I guess bytes streams could be shared across threads or tasks, right ? Having a Writer in a thread and a Reader in another thread, sharing the same fixed buffer ?
Only if you make an implementation that has its own buffer, separate from the interface buffers, and make that implementation thread/concurrency safe (raw threads or Io respectively).
If you just use the existing fixed implementations, it would break even in a single thread/task! The Reader and Writer have no way of knowing what the other does with the buffer, or that it is even shared at all!