Code review comment for lp:~kdub/mir/fix-1158564

> > 53 + std::shared_ptr<struct alloc_device_t> alloc_device;
> > 54 std::shared_ptr<mga::AndroidBuffer> android_buffer;
> > 55 std::shared_ptr<mga::AndroidBuffer> second_android_buffer;
> >
> > Yikes. If you're having that issue, what I would suggest doing would be
> > either:
> >
> > a) Add a comment saying that this needs to be the order and hope it stays
> up-
> > to-date
> > b) Wrap it all up into a new class, e.g:
>
> I prefer (if nothing is blocking it in this particular case):
>
> c) Make it so that destruction order doesn't matter. If all components that
> need an alloc_device_t hold a shared_ptr to it, then it will be destroyed at
> the right time, i.e., when no one needs it anymore.

This is also a good solution too as it doesn't seem like there would be an ownership cycle between both the buffers and the allocator here.

Originally I had quickly cast my mind to the case of relying on some implicit side-effect of alloc_device_t being open, and then not being able to have alloc_device_t own the buffers, but that was wrong.

Kevin, please disregard my earlier comment.