PullQueryable class

A queryable whose queries accumulate in a bounded channel, taken out on demand.

The channel-mode sibling of Queryable. Where a Queryable pushes every query into a stream as it arrives and buffers without bound, this holds at most capacity queries and lets the consumer set the pace.

The kind chosen at declaration decides what happens when the buffer fills: ChannelKind.ring drops the oldest query — remotely visible as that getter's timeout — while ChannelKind.fifo keeps every query and stalls inbound delivery instead.

Reply before you close. Drain only if the residue matters. close undeclares the queryable and releases the channel with whatever it holds. A query already taken out of the channel can still be replied to until then; canon calls replying after undeclare undefined behaviour, so this binding renders it as a contract rather than exposing a post-close drain window. (Measured at zenoh-c 1.8.0, subprocess-isolated: a reply attempted after undeclare returns normally and is silently dropped — no error and no crash. That is what makes a documented contract the proportionate rendering rather than a guard; it is not a licence to rely on it.)

⚠️ The drain half used to read "drain before you close", and it silently carried a CORRECTNESS claim it could not honour. Closing an undrained, overflowing fifo once hung the calling isolate permanently. That is fixed at the source, and draining could never have prevented it from one isolate anyway — measured at canon level, the hang persisted after the producer was gone. The REPLY half is unaffected and still binding: it is about canon's undefined behaviour after undeclare, not about this hang.

⚠️ One teardown ORDER still matters, and it is canon's, not this binding's: close pull handles before closing their session when a fifo may be in overflow. A session closed first still stalls — measured, and pinned as a residual in test/fifo_close_deadlock_test.dart. This unit does not fix that path.

The two terminal triggers differ in what they leave you: close releases this handle, so nothing can be polled afterwards, while the SESSION closing leaves the handle alive — a fifo then hands over what it still holds before reporting RecvDisconnected, and a ring discards it.

This object holds a native handle, so it cannot cross an isolate boundary: a copy would share this one's native address while carrying its own fresh disposal flag, and the second release would be a use-after-free. Sending it throws ArgumentError naming the class.

⛔ No NativeFinalizer is attached to this class, deliberately: as PullSubscriber — its close ordering is half Dart-side, which a finalizer callback cannot run. Releasing it explicitly is therefore the only thing that reclaims it.

Constructors

Properties

Methods

Operators

zenoh library