On Thu, Jun 27, 2019 at 09:50:08PM -0700, Michel Lespinasse wrote:
> As was already noted in rbtree.h, the logic to cache rb_first (or rb_last)
> can easily be implemented externally to the core rbtree api.
>
> Change the implementation to do just that. Previously the update of
> rb_leftmost was w
Hi Davidlohr,
On Fri, Jun 28, 2019 at 9:56 AM Davidlohr Bueso wrote:
> I think this makes sense, and is more along the lines of the augmented
> cached doing the static inline instead of separate instantiations of the
> calls.
Thanks for the review.
> >Change-Id: I0cb62be774fc0138b81188e6ae81d5f
On Thu, 27 Jun 2019, Michel Lespinasse wrote:
As was already noted in rbtree.h, the logic to cache rb_first (or rb_last)
can easily be implemented externally to the core rbtree api.
Change the implementation to do just that. Previously the update of
rb_leftmost was wired deeper into the implemn
On Thu, 27 Jun 2019, Michel Lespinasse wrote:
As was already noted in rbtree.h, the logic to cache rb_first (or rb_last)
can easily be implemented externally to the core rbtree api.
Change the implementation to do just that. Previously the update of
rb_leftmost was wired deeper into the implemn
As was already noted in rbtree.h, the logic to cache rb_first (or rb_last)
can easily be implemented externally to the core rbtree api.
Change the implementation to do just that. Previously the update of
rb_leftmost was wired deeper into the implemntation, but there were
some disadvantages to that
5 matches
Mail list logo
