engine::PulseEvent Class Reference

#include <userver/engine/pulse_event.hpp>

Detailed Description

A multiple-producers, multiple-consumers notification.

Subscribe issues a one-shot PulseEventSubscription. Any Send after that satisfies it; a Send that happened before Subscribe does not count. After that first Send, the subscription stays ready; call Subscribe again to wait for later signals.

This is unlike engine::MultiConsumerEvent, which latches a single global signal forever after the first Send (equivalent to engine::SingleConsumerEvent::NoAutoReset).

PulseEventSubscription is compatible with engine::WaitAny and friends. PulseEvent itself is not an awaitable: wait on a subscription from Subscribe.

See also

Synchronization primitives (PulseEvent overview and example)

Definition at line 92 of file pulse_event.hpp.

Public Member Functions
	PulseEvent (const PulseEvent &)=delete
	PulseEvent (PulseEvent &&)=delete
PulseEvent &	operator= (const PulseEvent &)=delete
PulseEvent &	operator= (PulseEvent &&)=delete
PulseEventSubscription	Subscribe () noexcept
	Issues a one-shot subscription that later Send calls can satisfy.
template<typename Predicate>
FutureStatus	WaitUntil (Deadline, Predicate stop_waiting)
	Works like std::condition_variable::wait_until. Waits until stop_waiting becomes true, and we are notified via Send.
void	Send () noexcept

Member Function Documentation

Send()

void engine::PulseEvent::Send ( )

noexcept

Wakes all tasks that currently wait on this event, if any. Also satisfies every subscription already issued, so a Send that races with Subscribe is not lost.

You can safely invoke Send from outside a coroutine.

WaitUntil()

template<typename Predicate>

FutureStatus engine::PulseEvent::WaitUntil ( Deadline deadline, Predicate stop_waiting )

nodiscard

Works like std::condition_variable::wait_until. Waits until stop_waiting becomes true, and we are notified via Send.

If stop_waiting is already true, returns right away.

Unlike std::condition_variable and engine::ConditionVariable, there are no locks around the state watched by stop_waiting, so that state must be atomic. std::memory_order_relaxed is OK inside stop_waiting and inside the notifiers as long as it does not mess up their logic.

For a full example, see engine_pulse_event.

Returns

FutureStatus::kReady if stop_waiting became true, FutureStatus::kCancelled if the current task was cancelled, FutureStatus::kTimeout if the deadline was reached.

Definition at line 137 of file pulse_event.hpp.

Friends And Related Symbol Documentation

PulseEventSubscription

friend class PulseEventSubscription

friend

Definition at line 130 of file pulse_event.hpp.

---

The documentation for this class was generated from the following file:

• userver/engine/pulse_event.hpp