Пользователи должны иметь точный контроль над подключением сигналов к слотам и их возможным отключением. Основной подход, принятый Boost. Signals2 возвращает объект signals2::connection, который позволяет подключать/отключать запрос, ручное отключение и автоматическое отключение в режиме разрушения (signals2::scoped_connection). Кроме того, два других интерфейса поддерживаются методом перегрузки ::disconnect:

Автоматическое управление соединением в Signals2 зависит от использования boost::shared_ptr для управления временем жизни отслеживаемых объектов. Он отличается от оригинального Boost. Библиотека сигналов, которая вместо этого опиралась на вывод из класса boost::signals::trackable. Библиотека будет уведомлена об уничтожении объекта с помощью разрушителя boost::signals::trackable.

К сожалению, схема boost::signals::trackable не может быть безопасна из-за порядка разрушителя. Деструктор класса, полученного из boost::signals::trackable, всегда будет называться перед деструктором основания boost::signals::trackable class. Однако для обеспечения безопасности потока соединение между сигналом и объектом должно быть отключено до того, как объект запустит свои деструкторы. В противном случае, если объект, разрушаемый в одной нити, соединен с сигналом, одновременно вызывающим в другой нити, сигнал может вызвать частично разрушенный объект.

Мы решаем эту проблему, требуя, чтобы отслеживаемые объекты управлялись с помощью shared_ptr. Слоты сохраняют weak_ptr для каждого объекта, от которого зависит слот. Подключения к слоту отключаются, когда истекает срок действия любого из отслеживаемых weak_ptr. Кроме того, сигналы создают свои собственные временные shared_ptr для всех отслеживаемых объектов слота до вызова слота. Это гарантирует, что ни один из отслеживаемых объектов не будет уничтожен в середине вызова.

Новая схема управления подключением имеет преимущество в том, что она не навязчива. Объекты любого типа можно отслеживать с помощью схемы shared_ptr/weak_ptr. Старая схема boost::signals::trackable требует, чтобы отслеживаемые объекты были получены из базового класса trackable, что не всегда практично при взаимодействии с классами из 3-й партийной библиотеки.

Комбинатор по умолчанию для Boost. Сигналы2 изменились с комбинатора last_value, используемого по умолчанию в исходном Boost. Библиотека сигналов. Это связано с тем, что last_value требует, чтобы по меньшей мере 1 слот был подключен к сигналу при его вызове (за исключением специализации last_value). В многопоточной среде, где вызовы сигналов и соединения слотов и отключения могут происходить одновременно, трудно выполнить это требование. При использовании optional_last_value не требуется подключение слотов при вызове сигнала, поскольку в этом случае комбинатор может просто вернуть пустое boost::optional.

Интерфейс Combiner был выбран для имитации вызова алгоритма в стандартной библиотеке C++. Считается, что, рассматривая результаты вызова слота как просто последовательность значений, доступных с помощью итераторов ввода, интерфейс комбинатора будет наиболее естественным для опытного программиста C++. Конкурирующий дизайн интерфейса обычно требовал, чтобы комбинаторы были построены в соответствии с интерфейсом, который будет настроен для (и ограничен) библиотеки Signals2. Хотя эти интерфейсы, как правило, обеспечивают более простую реализацию сигналов и усилителей; библиотеки слотов, комбинаторы, к сожалению, не могут быть повторно использованы (либо в других сигналах и усилителях; библиотеки слотов или в других общих алгоритмах), и кривая обучения немного покручена, чтобы изучить конкретный интерфейс комбинатора.

Формулировка комбинаторов Signals2 основана на комбинаторе, использующем режим «тяги» связи, вместо более сложного механизма «толкания». С механизмом «вытягивания» состояние комбинатора может храниться на стеке и в счетчике программы, потому что всякий раз, когда требуются новые данные (т.е. вызов следующего слота для извлечения его обратного значения), существует простой интерфейс для извлечения этих данных немедленно и без возвращения из кода комбинатора. Сравните это с механизмом «толчка», где комбинатор должен сохранять все состояние в классе, потому что для каждого сигнала, называемого комбинатором, будут использоваться процедуры комбинатора. Сравните, например, комбинатор, который возвращает максимальный элемент от вызова слотов. Если максимальный элемент когда-либо превышает 100, больше слотов не будет.

struct pull_max {
  typedef int result_type;
  template<typename InputIterator>
  result_type operator()(InputIterator first,
                         InputIterator last)
  {
    if (first == last)
      throw std::runtime_error("Empty!");
    int max_value = *first++;
    while(first != last && *first <= 100) {
      if (*first > max_value)
        max_value = *first;
      ++first;
    }
    return max_value;
  }
};

struct push_max {
  typedef int result_type;
  push_max() : max_value(), got_first(false) {}
  // returns false when we want to stop
  bool operator()(int result) {
    if (result > 100)
      return false;
    if (!got_first) {
      got_first = true;
      max_value = result;
      return true;
    }
    if (result > max_value)
      max_value = result;
    return true;
  }
  int get_value() const
  {
    if (!got_first)
      throw std::runtime_error("Empty!");
    return max_value;
  }
private:
  int  max_value;
  bool got_first;
};

В этих примерах следует отметить несколько моментов. Версия «pull» является многоразовым функциональным объектом, который основан на последовательности итератора ввода с целым числом value_type и очень прост в дизайне. Модель «push», с другой стороны, опирается на интерфейс, специфичный для абонента, и обычно не используется повторно. Это также требует дополнительных значений состояния, чтобы определить, например, были ли получены какие-либо элементы. Хотя качество кода и простота использования, как правило, субъективны, модель «вытягивания» явно короче и более многоразовая и часто будет рассматриваться как более простая в написании и понимании, даже вне контекста библиотеки сигналов и усилителей.

Стоимость интерфейса комбинатора «pull» оплачивается при реализации самой библиотеки Signals2. Чтобы правильно обрабатывать отключения слотов во время вызовов (например, когда вызывается оператор отсчета), необходимо построить итератор, чтобы пропустить отключенные слоты. Кроме того, итератор должен нести с собой набор аргументов для передачи в каждый слот (хотя достаточно ссылки на структуру, содержащую эти аргументы), и должен кэшировать результат вызова слота, чтобы множественные ссылки не приводили к нескольким вызовам. Это, по-видимому, требует большой степени накладных расходов, хотя, если рассматривать весь процесс вызова слотов, можно увидеть, что накладные расходы почти эквивалентны таковым в модели «толчка», но мы перевернули структуры управления, чтобы сделать комплекс итерации и отсчета (вместо того, чтобы делать комбинаторный комплекс определения состояния).

Boost.Signals2 поддерживает синтаксис соединения с формой sig.connect(slot), но предложен более строгий синтаксис sig += slot (и использовался другими сигналами & реализациями слотов). Существует несколько причин, по которым этот синтаксис был отклонен:

Библиотека Boost.Signals2 предоставляет 2 класса mutex: boost::signals2::mutex и boost::signals2::dummy_mutex. Мотивация для предоставления boost::signals2::mutex заключается просто в том, что класс boost::mutex предоставлен Boost. В настоящее время библиотека Thread требует ссылки на libboost_thread. Класс boost::signals2::mutex позволяет Signals2 оставаться библиотекой только для заголовков. При желании вы можете использовать boost::mutex, указав его в качестве шаблона Mutex для ваших сигналов.

Класс boost::signals2::dummy_mutex позволяет чувствительным к производительности однопоточным приложениям минимизировать накладные расходы, избегая ненужной блокировки mutex.