[Bro-Dev] 0MQ security considerations
gc355804 at ohio.edu
Thu Jul 7 16:04:17 PDT 2011
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.
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
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.
> 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
Also, the dependencies involved with boost do suck, but pushing
maintenance onto someone else can be a huge win.
More information about the bro-dev