[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 03/16] job.h: define locked functions
From: |
Emanuele Giuseppe Esposito |
Subject: |
Re: [PATCH v3 03/16] job.h: define locked functions |
Date: |
Wed, 26 Jan 2022 16:58:40 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 |
On 24/01/2022 15:26, Paolo Bonzini wrote:
> On 1/21/22 17:04, Vladimir Sementsov-Ogievskiy wrote:
>>>
>>> The split was proposed in previous versions, but Vladimir did not
>>> really like it and suggested to send it as a separate series:
>>
>> I didn't really like it as it seemed unusual and unobvious to me. But
>> if we already accepted similar split for generic block layer, no way
>> for me to resist :) And if we follow new logic of generic block layer
>> in jobs, it's not "unusual" any more.
>
> Either way I think it's okay to have it as a follow-up. The explicit
> naming in the API is a bit verbose but definitely clearer, so it's okay
> to order different than the graph/IO split. In that case we weren't
> even sure, until you went through all the testcase failures, that a
> _locked or rather "_drained" API was possible.
>
> Paolo
>
Ok, I will send the split in a separate series.
Thank you,
Emanuele
- [PATCH v3 09/16] jobs: remove aiocontext locks since the functions are under BQL, (continued)
Re: [PATCH v3 00/16] job: replace AioContext lock with job_mutex, Paolo Bonzini, 2022/01/19