[zeromq-dev] Proposal for a revised zlist API

[Pieter Hintjens]

Sorry, I've lost track of some of the details here. Could you
re-describe your timeout queue starting from the problem so I can
think about how I'd implement it?

Thanks
Pieter

On Wed, Sep 10, 2014 at 6:28 PM, Goswin von Brederlow <goswin-v-b at web.de> wrote:
> 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?
>
> MfG
>         Goswin
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev