On Thu, 2008-05-15 at 08:33 +0100, Christine Caulfield wrote: > Steven Dake wrote: > > currently the objdb interface is in a bit of a messy state. The reason > > is the need for iteration contexts for multiple iterators on the same > > object or different objects at around the same time. > > > > This patch removes objdb_find_reset and objdb_find and replaces them > > with object_find_create, object_find_next, and object_find_destroy. > > > > When an iterator is created, objdb_find_create is used. This creates a > > handle context which then can be used with objdb_find_next to iterate > > that object. Once the service engine is done with the iterator, it > > would call object_find_destroy. > > > > At this time object deletion is not supported during iteration, but that > > will be added in a future patch as the need arises. > > > > Next up is the key iteration following this same api model. > > As an API I'm happy with that. I'm less happy about it storing pointers > to objects as part of the context. It makes a DoS attack from a library > user trivial. Create an iterator, iterate to an element, delete it, boom! >
Yeah definitely the implementation of of the API needs some work and in truth was hacked together to "just make it work". The basic idea of this patch is to unblock Andrew and the pacemaker service engine and settle on an API so I can work on other issues. I am going to rework the implementation at a later time before corosync 1.0 is released. On a side note, I know it is alot of work for cman to convert the API around. But I wanted to make sure this makes sense for the CMAN service engine as well and you would be willing to make the changes. Regards -steve > I know you say that "deletion is not supported during iteration" but > that's not quite the same thing :-) > > Anyway, once that's sorted out I think object_iter will be trivial to > convert before moving onto the key iterator. > > I wonder if we could get rid of object_iter entirely by passing a NULL object and value into the find function. A little bit of overloading, but not totally out of the norm... Regards -steve _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
