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.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to