Re: [devel] I: git.alt update

["Dmitry V. Levin" <ldv@altlinux.org>]

[-- Attachment #1: Type: text/plain, Size: 2734 bytes --]

On Tue, Nov 23, 2010 at 02:11:02AM +0300, Alexey Tourbin wrote:
[...]
> С другой стороны, смотри.  Узнать, что репозиторий изменился (и что
> придётся проигрывать всё задание заново) можно гораздо раньше, чем
> в самом конце при попытке коммита задания.

Вопрос в том, всегда ли интересно узнать это гораздо раньше?
Я полагаю, что сборку задания имеет смысл довести до конца,
не интересуясь изменением репозитория, в двух случаях:
- задание test-only (его всё равно не придется коммитить);
- номер итерации задания равен 1 (не факт, что оно вообще соберется);

> Это также наводит на мысль, что клонировать репозиторий нет необходимости.
> Достаточно иметь операцию
> 
> lock_repo_for_reading,check_the_repo_is_unchanged,otherwise_fail_and_schedule_task_for_reiteration
> 
> Далее нарезать girar-builder, чтобы некоторые куски выполнялись под этим
> локом, а некоторые - без него. Наример, gb-remote-build нужно разрезать на
> две части: первая часть выполнятеся под локом, она готовит чрут для сборки
> (в том числе выгребает пакеты из репозитория).  Вторая часть просто
> собирает пакет - упрощенно говоря 'hsh-run rpmbuild ...', лок на
> репозиторий для этого не нужен.

Пожалуй, можно так сделать, и обработка задания тогда будет прерываться
быстрее, чем сейчас.  Но что это даст на практике?  Сейчас, судя по
таймингам в логах сборки, задание с номером итерации > 1 проводит очень
много времени в gb-task-gen-testrepo, и с этим пока ничего не получается
сделать.  apt -- наш главный тормоз как при вычислении зависимостей
(high startup costs), так и при вычислении индексов.

$ egrep '^(Mem|Buffers|Cached|Active|Inactive|Slab)' /proc/meminfo
MemTotal:     24627408 kB
MemFree:       1032952 kB
Buffers:        737652 kB
Cached:       20408488 kB
Active:        5720820 kB
Inactive:     15464156 kB
Slab:          2271392 kB

> > задание переводится в состояние COMMITTING, репозиторий обновляется,
> > и выполнение задания завершается.
> > > Гарантируется ли строгая (логическая) сериализация заданий?
> > А что это значит?
> 
> Это понятие из теории СУБД.  Транзакции могут выполняться параллельно,
> но с точки зрения самой транзакции она выполняется как бы эксклюзивно,
> а результат параллельного выполнения должен быть такой, как если бы
> транзакции выполнялись в каком-либо порядке.  Иначе возникают неприятные
> побочные эффекты (самый известный и простой - продать два билета на одно
> место).

В этом смысле да, такая сериализация заданий гарантируется.
При условии что gb-task-validate-state и кэширование в
gb-remote-build/gb-remote-check-install реализовано правильно, конечно.

> Т.е. одно коммитится, все остальные идут на реитерацию.

Да.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]