postage-rs issues

Results 17 postage-rs issues

Sort by recently updated

Clarify behaviour on drop of watch::Sender

The `Sender` isn't `Clone` so there can only be one. But, what happens if it's dropped? The existence of `Receiver::borrow` implies that the contained value cannot be dropped until the...

ijackson

Would like watch::Sender::send_if_changed` or borrow_then_send_if_changed

In some use cases the contained value is `PartialEq` and it might be nice to be able to avoid waking up the receivers if the value to be sent hasn't...

ijackson

Would like non-async sender on postage::watch

`postage::watch::Sender` offers, really, just the interface of `Sink`. But in fact its implementation never blocks (never returns `Pending`). It would be nice to make this a formal part of the...

ijackson

Implement a lagging broadcast channel

I'd like to support the lagging broadcast channel that tokio provides, so postage can be fully compatible with existing tokio code. I think the current channel is useful, but it...

austinjones

Add loom tests

Loom https://github.com/tokio-rs/loom This can be a significant amount of work but in my experience it is MUCH more effective catching concurrency bugs compared to stress tests. Eg. https://github.com/tokio-rs/tokio/blob/master/tokio/src/sync/tests/loom_broadcast.rs

arthurprs

Minimize the number of woken senders/receivers

Other channel implementations (such as the async-std channel) limit the number of woken senders/receivers. It would be trivial to implement this in the Notifier struct. However, it needs some thought....

austinjones

Implement std Stream for all receivers

Once std Stream is stabilized, implement it for all channel receivers.

austinjones

FilterStream needs some kind of backoff/sleep

The FilterStream currently loops on Ready values, until a match is found. It's possible to write a malicious stream and filter that would infinitely loop: ``` filter = |v| false;...

austinjones