This is part of my work to reduce the thread count of Songbird, to majorly improve performance and reduce load on the scheduler.
Adds a new field to Config, disposer, an Option<Sender<DisposalMessage>> responsible for dropping the DisposalMessage on a separate thread.
If this is not set, and the Config is passed into manager::Songbird, a thread is spawned for this purpose (which previously was spawned per driver).
If this is not set, and the Config is passed directly into Driver or Call, a thread is spawned locally, which is the current behavior as there is no where to store the Sender.
This disposer is then used in Driver as previously, to run possibly blocking destructors (which should only block the disposal thread). I cannot see this disposal thread getting overloaded, but if it is the DisposalMessages will simply be queued in the flume channel until it can be dropped.
This is part of my work to reduce the thread count of Songbird, to majorly improve performance and reduce load on the scheduler.
Adds a new field to Config,
disposer, anOption<Sender<DisposalMessage>>responsible for dropping theDisposalMessageon a separate thread.If this is not set, and the
Configis passed intomanager::Songbird, a thread is spawned for this purpose (which previously was spawned per driver). If this is not set, and theConfigis passed directly intoDriverorCall, a thread is spawned locally, which is the current behavior as there is no where to store theSender.This
disposeris then used inDriveras previously, to run possibly blocking destructors (which should only block the disposal thread). I cannot see this disposal thread getting overloaded, but if it is theDisposalMessages will simply be queued in the flume channel until it can be dropped.