Open kbleeke opened 2 months ago
Pipe
is a byte stream, it doesn't make sense to use it with multiple writers for packet-based data.
If we wanted to support this we'd have to add something like a "packet-based PIpe". You might want to check out bbqueue
which is exactly that, it has async support I think.
I looked at bbqueue before but it seems to be purely SPSC
I'm using
embassy_sync::Pipe
to distribute variable sized messages within my application. The messages are framed and there is a single reader for each pipe. This works fine. (is there a better way?)I have multiple writers that use
write_all
to push messages into the pipe. As long as the pipe is not full this should be fine, as the writers take the lock and write the message in asingle
write() call. However, I believe this has a race condition when the Pipe is full and multiple writers are racing to push more bytes into the pipe. It's not a data race but (at least in my case) simply undesired behavior.I'm currently preventing this by acquiring an extra mutex for writing into the pipe. Does it ever make sense that concurrent
write_all()
s are racing? Would it make sense to acquire the pipe's internal mutex for the entire duration of write_all instead?