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