When porting portal to use priority channels, I've realized actor systems may
want to set capacity of the normal channel as low as 1 (for actors that cannot
keep up with the pace, but for which that doesn't matter).
Producers of their "bulk" low-priority messages will usually ignore their
channels being full. OTOH producers of their important high-priority messages
may like to fail when their priority channel is full (as ignoring that may
have dire consequences). It would be thus impractical if the priority channel
got similarly small capacity. (actor needs to finish at least one event loop
to get to process the high-prio messages).
There is quite some freedom in how to design API of this, so I thought it would be handy to run this as a separate PR that targets #62.
…y channel
When porting portal to use priority channels, I've realized actor systems may want to set capacity of the normal channel as low as 1 (for actors that cannot keep up with the pace, but for which that doesn't matter).
Producers of their "bulk" low-priority messages will usually ignore their channels being full. OTOH producers of their important high-priority messages may like to fail when their priority channel is full (as ignoring that may have dire consequences). It would be thus impractical if the priority channel got similarly small capacity. (actor needs to finish at least one event loop to get to process the high-prio messages).
There is quite some freedom in how to design API of this, so I thought it would be handy to run this as a separate PR that targets #62.