[Bro-Dev] libbroker status/plans

Gilbert Clark 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 
its own.

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 
[1].  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.


[1] http://actor-framework.org/pdf/cshw-nassp-13.pdf

 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) reflects the common experience that 
message passing with restricted types is of limited use in practice. 
However, unrestricted messaging requires efficient and expressive 
facilities such as pattern matching (c), because message handling is a 
continuously recurring task to implement."

More information about the bro-dev mailing list