20 lines
972 B
ReStructuredText
20 lines
972 B
ReStructuredText
|
Rework our ``.trionics.BroadcastReceiver`` internals to avoid method
|
||
|
|
recursion and approach a design and interface closer to ``trio``'s
|
||
|
|
``MemoryReceiveChannel``.
|
||
|
|
|
||
|
|
The details of the internal changes include:
|
||
|
|
|
||
|
|
- implementing a ``BroadcastReceiver.receive_nowait()`` and using it
|
||
|
|
within the async ``.receive()`` thus avoiding recursion from
|
||
|
|
``.receive()``.
|
||
|
|
- failing over to an internal ``._receive_from_underlying()`` when the
|
||
|
|
``_nowait()`` call raises ``trio.WouldBlock``
|
||
|
|
- adding ``BroadcastState.statistics()`` for debugging and testing both
|
||
|
|
internals and by users.
|
||
|
|
- add an internal ``BroadcastReceiver._raise_on_lag: bool`` which can be
|
||
|
|
set to avoid ``Lagged`` raising for possible use cases where a user
|
||
|
|
wants to choose between a [cheap or nasty
|
||
|
|
pattern](https://zguide.zeromq.org/docs/chapter7/#The-Cheap-or-Nasty-Pattern)
|
||
|
|
the the particular stream (we use this in ``piker``'s dark clearing
|
||
|
|
engine to avoid fast feeds breaking during HFT periods).
|