Re: [I] Tracking Issue to deliver the channel family incrementally [asyncband]

["tisonkun (via GitHub)" <gi...@apache.org>]

tisonkun commented on issue #206:
URL: https://github.com/apache/asyncband/issues/206#issuecomment-5428353929

   One follow-up API consideration for bounded queues is **public capacity reservation**, distinct from the private sequence/publication reservations discussed in #167.
   
   A `send(value)` future owns `value` while it waits for capacity. If the future is used in a race or selection operation and another branch wins, dropping the send future also drops the unsent value. Splitting capacity acquisition from value transfer lets callers wait without moving the payload into a cancellable future:
   
   ```rust
   let permit = sender.reserve().await?;
   permit.send(value);
   ```
   
   A possible contract is:
   
   - `reserve()` waits for one strict logical capacity slot and returns a borrowed RAII permit;
   - `try_reserve()` performs the same operation without waiting;
   - a permit guarantees that one later send will not fail with `Full`;
   - `Permit::send(value)` consumes the permit and commits the value;
   - dropping an unused permit returns its slot;
   - cancelling a pending reservation does not consume capacity, but loses its place in the existing FIFO waiter queue;
   - channel disconnection fails the reservation without requiring a payload to recover;
   - reserved-but-unused slots count against reported available capacity.
   
   Tokio uses this distinction specifically to avoid losing a payload when `send` is cancelled in `select!`: https://docs.rs/tokio/latest/tokio/sync/mpsc/struct.Sender.html#method.reserve
   
   Open questions include borrowed versus owned permits, whether `reserve_many` has a demonstrated use case, and which channel topologies should expose the API. Point-to-point bounded queues are the clearest first target. Broadcast reservation has additional contiguous-publication concerns: an earlier outstanding permit must not let a later publication become visible out of order.
   
   This should not block the current incremental delivery plan. It is a public API/cancellation contract to evaluate after the bounded backend is established, and it does not reopen the separately excluded rendezvous-channel design.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@asyncband.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@asyncband.apache.org
For additional commands, e-mail: commits-help@asyncband.apache.org