Marco

I see I’ve been getting a bunch of traffic on this post from some group in LinkedIn, but since I’m not a member of that (or any) group in LinkedIn, I can’t even see what the group is let alone why you folks are visiting here…

Anyone care to enlighten me? Thanks!

For layering purposes perhaps have queue managers that would take the last “position” as a request parameter and return 1-N available updates if any present. Since it’s read only memory to all but one locking/blocking should be minimal.

Queue managers, server processes, could be placed in front of pools of consumers and provide answers based on reading snapshots from the master queue. It would be possible for queue managers to have different filtering capabilities if not all messages were useful for all potential clients.

Heh, obviously, I like to roll my own solutions, but that doesn’t always work well with trying to fit into some massive organized framework. It is however fun when there are no real world issues to deal with during the design process…

Getting a clue. If I dust-off my vintage WR Stevens book and turn to chapter 12 on advanced i/o, I learn about select() in about six (dense) pages. I’m forced to learn about the arguments it takes and a variety of macros for manipulating them. Admittedly, it’s not easy to use select() correctly. (Indeed, I’ve already been informed that my little example Emitter has at least one error and readily admit that it suffers from use in an example that’s contrived-to-the-point-of-absurdity.) But to get the basic idea of it doesn’t take much more than reading a few man pages.

Going to boost::asio’s reference almost couldn’t be a more removed experience. I didn’t bother to count, but there must be nearly 100 classes/templates/options/services/functions/&tc to wade through.

I experienced terrifying flashbacks of Sun’s visionary decision to put corba and rmi in the java class library.

I’m sure that once you get ‘grounded’ in the asio mindset it all makes sense and is very clean and nice, but I just wanted to whip together a simple example and get on with my day. The fact that google doesn’t include asio in the teeny sliver of boost that they allow, didn’t much inspire me to make the investment of time.

But my real point was the difference I saw in using the two libraries. boost::asio has been around for a long time and has good documentation (I think – certainly there’s plenty of it), but I found it hard to understand and get to work as desired. Fastflow is doing non-trivial stuff, is brand new and has practically no documentation, but using it was very easy – there’s not a lot of concepts you need to learn because the designers kept it simple and used layers of abstraction to hide things you might not initially care about.

Best,