[Bro-Dev] libbroker status/plans
gc355804 at ohio.edu
Wed Oct 22 15:07:48 PDT 2014
Two thoughts inline:
On 10/22/2014 3:39 PM, Siwek, Jon wrote:
> - C API
Do we need a vanilla C API in addition to the C++ API offered? Could be
that this was a requirement, so won't argue the point: just making sure
someone asked this question.
> - Need/want overload or flow-control mechanisms?
> E.g. a simple policy for handling overload is to let a user specify
> a threshold for how many items are allowed in a queue before new
> messages are dropped.
More general question: are there expectations of reliability on broker
messages? I'm not really familiar enough with the actor model in
general / this library to know. Depending on the protocol being used,
it could also be that the transport is going to provide flow-control of
Also, one thing that might concern me a little is that, based on a very
limited understanding of CAF, messages appear to be garbage collected
. How are the messages GC'd? Depending on how the GC works, my
concern there would be that a poorly-timed GC cycle could lead to drops.
From 4.1 -
"Message Handling and Processing: Messages shall (a) be garbage
collected, (b) not be limited to particular types, and (c) provide
pattern matching. Requirement (a) is owed to the experience that manual
memory management in concurrent systems is error-prone and thus
impractical, while the alternative approach of copying a message for
each single recipient, leads to suboptimal performance if a message has
multiple recipients. Requirement (b) reﬂects the common experience that
message passing with restricted types is of limited use in practice.
However, unrestricted messaging requires efﬁcient and expressive
facilities such as pattern matching (c), because message handling is a
continuously recurring task to implement."
More information about the bro-dev