On 5/12/20 3:39 AM, Michał Górny wrote:
> W dniu wto, 12.05.2020 o godzinie 01∶40 -0700, użytkownik Zac Medico
> napisał:
>> On 5/11/20 10:54 PM, Michał Górny wrote:
>>> W dniu nie, 10.05.2020 o godzinie 21∶32 -0700, użytkownik Zac
>>> Medico
>>> napisał:
>>>> The feature enables finer grained locks for install operations,
>>>> and
>>>> everyone agrees that it's safe to enable by default.
>>> Who's 'everyone' and where's their analysis of the problem?
>>> The manpage doesn't really help understand what this does, exactly.
>> Before parallel-install there was just one big lock, so only one
>> package
>> slot could enter the merge/unmerge state at a given time.
>> With parallel install, there are a few finer-grained locks that come
>> into play. [...]
> I'm sorry but I was asking of a more high-level implications.
> I presume that this means that more than files of more than one package
> can be merged simultaneously.  However:

No, an exclusive lock must be held on vardbapi._fs_lock for this. This
is currently required at least to guarantee that access to the config
memory file is serialized (config memory is the thing that emerge
--noconfmem disables, but --noconfmem does not disable this lock).

We assume that it's probably not worthwhile to try to merge files for
more than one package at a time, since that would cause them to compete
for IO bandwidth.

> 1. Are collisions handled correctly then?  i.e. if you start installing
> A, and then B, and the two packages collide will portage fail before
> starting to install any file from B?

There are no guarantees here. However, the risk is minimal, since it's
unlikely that a file collision of this sort would occur. file collisions
are a QA problem that is generally detected and corrected log before we
would encounter a collision of this sort.

> 2. Are preinst/postinst phases called simultaneously or serialized?

They're serialized.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to