On 02/26/2018 04:29 AM, Michał Górny wrote: > W dniu nie, 25.02.2018 o godzinie 17∶50 -0800, użytkownik Zac Medico > napisał: >> Add async_aux_get method that returns a Future and otherwise >> behaves identically to aux_get. Use async_aux_get to implement >> the synchronous aux_get method. >> >> Bug: https://bugs.gentoo.org/648790 >> --- >> pym/portage/dbapi/porttree.py | 91 >> +++++++++++++++++++++++++++++++++---------- >> 1 file changed, 70 insertions(+), 21 deletions(-) >> > > What's the exact use case? What's the gain, in numbers?
I'm planning to use the for repoman, since it commonly has to generate metadata for multiple packages a once, when dealing with ebuild or eclass modifications. The gain in numbers is that it scales linearly with the number of available cores. > This seems like a lot of added complexity. It doesn't really add complexity, asynchronous code or this sort is already used throughout portage internals. Asynchronous methods like these are quite standard today, thanks to asyncio. > With Portage being practically unmaintainable, Any reasonably complex codebase appears to be unmaintainable to those who don't maintain it. > I'm against any changes that make things worse without > clearly defined major benefit. Transitioning to asynchronous interfaces like this is unavoidable as we move into the realm of asyncio compatibility. -- Thanks, Zac
signature.asc
Description: OpenPGP digital signature
