[Bro-Dev] 0MQ security considerations

[Gilbert Clark]

On 7/7/2011 5:51 PM, Robin Sommer wrote:
> Gilbert, the next question then is however if we really want to use
> 0mq for the inter-thread communication. That idea was based on the
> assumption that we'd be using it anyway, which doesn't necessarily
> seem to be the case anymore.

*nod* Yeah.

I'll be very sad to see the lock-free synchronization go.  I'll 
additionally hate to lose the constraints 0mq enforces on design; 
there's a little bit of coding around the library to do, but in this 
case I think it'd lead to a cleaner overall design than we may get 
otherwise.

I don't know whether the above necessarily justifies introduces the 
additional dependency, though, especially when I'm not sure exactly how 
much of a win the lock-free stuff would actually turn out to be.

> Should we just bite the bullet and do a pure pthreads implementation?
> We could encapsulate the thread management into a class ThreadMgr that
> would take care of starting/stopping/etc. threads, and a new class
> Thread would be the top-level class for LogWriters to be derived from.

0mq doesn't completely eliminate the need for threads; we still need the 
LogWriter running in its own context.  Thus, building a thread manager 
is definitely on the to-do list.

First, though, I thought I'd look around for a library that does 
something like that.  If I can't find one, then it'll be time to build one.

> Robin
>
> PS: Yeah, I know, C++0x will make everything better ... And I'm still
> very reluctant to pull Boost in ...

Python would make everything better.  C++0x will just make things more 
complicated.  /cynical

Also, the dependencies involved with boost do suck, but pushing 
maintenance onto someone else can be a huge win.

--Gilbert