[zeromq-dev] Proposal for a revised zlist API

Goswin von Brederlow goswin-v-b at web.de
Wed Sep 10 18:28:43 CEST 2014

On Mon, Sep 08, 2014 at 07:02:53PM +0200, Pieter Hintjens wrote:
> On Mon, Sep 8, 2014 at 6:42 PM, Goswin von Brederlow <goswin-v-b at web.de> wrote:
> > Urgs.
> :-)
> > If zlist gets deprecated then there needs to be a new list (zring)
> > that preserves the strict fifo ordering and simplicity of a list.
> We don't need to deprecate zlist then, rather we can keep it as the
> simple list container.
> > Merging them together generaly just combines
> > the bad aspects while loosing the good.
> Not really. I've experimented with the zring hybrid and it works very
> neatly, and it solves the case we have often, of keeping a list+hash
> of items. In fact the only case I've seen of code using two containers
> for the same data.
> > This new mix
> > with a hashtable makes the class unusable from an API point too.
> How? If you don't use the keyed calls, it works just like before.

But my timeout queue needs the key api (or rather the initial
zdlist_node_t*) to access items diretly. So I have to invent keys and
convert them to strings to use the key API and implement my own detach
by key.

> > And you can't
> > detach/delete an item by key, which would be the only point in all of
> > this for me. (Note: I do need that zring_node_t * return value for
> > append back by the way).
> If you have keys for an item then you use _insert to store them, and
> then _delete to remove by key.

But not detach it by key. The delete destroys the item.

> > On the other hand the extra arg is invaluable when combinging or
> > stacking containers or stacking of free_fn functions.
> Which is a use case that zring now kills off. Unless you have other
> mixes of containers.

I do. The timeout queue I posted a while back does use zring. That's
what I wrote it for. And with it being in the critical IO path the
speed of certain operations is important.
> It is demonstrably simpler to allow zring to do both list and hashing
> than manage two containers in the app, and adding user pointers just
> complexifies further.
> > size_t czmq_hash_fn (void *item, void *hash_private)
> Sure, yes. The hash item needs to also get the key, if any, used to
> insert the item.

My bad. Should have been

    size_t czmq_hash_fn (void *key, void *hash_private)

The hash function shouldn't need the item to hash a key. Otherwise how
is lookup going to work?


More information about the zeromq-dev mailing list