On Mon, Nov 22, 2010 at 10:12:09AM +0300, Alexey Tourbin wrote:
> On Wed, Nov 03, 2010 at 09:14:56AM +0300, Dmitry V. Levin wrote:
> > On Wed, Oct 27, 2010 at 10:57:48AM +0400, Dmitry V. Levin wrote:
> > > Сегодня и, возможно, последующие дни будет происходить ползучее обновление
> > > git.alt, поэтому просьба возможные отказы в обслуживании воспринимать
> > > соответствующим образом.
> > 
> > Основное обновление завершено.  Обработка заданий сейчас идет в три
> > сборочных потока (плюс один завершающий).  Наверное, эксперименты с
> > алгоритмом распараллеливания обработки будут продолжаться, но сбоев
> > и простоев больше быть не должно.
> 
> А какой принцип работы параллельной сборки?

girar-task-run поставляет задания в состоянии AWAITING;

N=3 экземпляра gb-toplevel-build выбирают задания в состоянии AWAITING,
приоритет имеет задание с меньшим номером;

выбранное задание переводится в состояние BUILDING, и для него клонируется
репозиторий;

для каждого аккаунта, зарегистрированного в системе, может быть не более
одного задания в состоянии BUILDING;

собранные test-only задания переводятся в состояние TESTED,
остальные собранные задания переводятся в состояние PENDING;

gb-toplevel-commit выбирает задания в состоянии PENDING c номером итерации
не менее чем максимальный номер итерации всех заданий в состоянии
BUILDING и PENDING для данного репозитория в данный момент времени,
приоритет имеет задание с меньшим номером;

если репозиторий, для которого задание было собрано, отличается от
репозитория, на котором оно было собрано, то задание переводится в в
состояние AWAITING с увеличенным номером итерации;

задание переводится в состояние COMMITTING, репозиторий обновляется,
и выполнение задания завершается.

> Гарантируется ли строгая (логическая) сериализация заданий?

А что это значит?

> Например, параллельно собирались два задания - glibc и rpm,
> и закончили собираться одновременно.  Как определить, сколько
> и какие именно задания будут завершены?

По алгоритму, приведенному выше.


-- 
ldv