On Fri, Apr 19, 2024 at 04:49 PM +0200, Marc Hartmayer
wrote:
> Use a worker pool for processing the events (e.g. udev, mdevctl config
> changes)
> and the initialization instead of a separate initThread and a mdevctl-thread.
> This has the large advantage that we can leverage the job API and
With the too-many-rebase-add-change and the additional comment
explaining why currently only one worker must be used
Reviewed-by: Boris Fiuczynski
On 4/19/24 16:49, Marc Hartmayer wrote:
Use a worker pool for processing the events (e.g. udev, mdevctl config changes)
and the initialization
On Mon, Apr 22, 2024 at 02:45:52PM +0200, Marc Hartmayer wrote:
> On Fri, Apr 19, 2024 at 04:49 PM +0200, Marc Hartmayer
> wrote:
> > Use a worker pool for processing the events (e.g. udev, mdevctl config
> > changes)
> > and the initialization instead of a separate initThread and a
> >
On Fri, Apr 19, 2024 at 04:49 PM +0200, Marc Hartmayer
wrote:
> Use a worker pool for processing the events (e.g. udev, mdevctl config
> changes)
> and the initialization instead of a separate initThread and a mdevctl-thread.
> This has the large advantage that we can leverage the job API and
On 4/19/24 11:04 AM, Marc Hartmayer wrote:
On Fri, Apr 19, 2024 at 04:49 PM +0200, Marc Hartmayer
wrote:
Use a worker pool for processing the events (e.g. udev, mdevctl config changes)
and the initialization instead of a separate initThread and a mdevctl-thread.
This has the large advantage
On Fri, Apr 19, 2024 at 04:49 PM +0200, Marc Hartmayer
wrote:
> Use a worker pool for processing the events (e.g. udev, mdevctl config
> changes)
> and the initialization instead of a separate initThread and a mdevctl-thread.
> This has the large advantage that we can leverage the job API and
Use a worker pool for processing the events (e.g. udev, mdevctl config changes)
and the initialization instead of a separate initThread and a mdevctl-thread.
This has the large advantage that we can leverage the job API and now this
thread pool is responsible to do all the "costly-work" and
