On 2013-08-23 10:28, Max Sikstrom wrote:
> From: Max Sikström
>
> A worker is a closed defined system that executes commands, and distributes it
> over several processes, and does it quite well.
>
> Because of the nature of a job to be asyncrhonous, the simplest way is to let
> worker handler job types to know what should be done when finished; start job,
> do other things, do some stuff when job is done, dependent on what job type it
> was.
>
> But that concept doesn't scale well when new kinds of jobs is needed, for
> example through nebmods, or new systems in the system. The worker code gets
> cluttered with non-worker related functionality, and some logic about the other
> parts functionality needs to be done within the worker module.
>
This part of the message doesn't make much sense without changes being
isolated mostly to lib/worker.c. Everything else relates to how the
scheduler handles communication with the workers, and has nothing to do
with actual workers as such.
> The concept of callbacks and pointers to functions is a much cleaner way to
> handle job results. Each module that uses the worker can define how to handle
> the job result itself instead. No special cases is needed in the worker code.
>
Except there's no single-point-of-entry where we can log errors in case
we do that, so each handler would need its own messages for that. I'm
not exactly thrilled about that.
So while we might be gaining cleaner code, we're losing error logging of
helpers that for various reasons fail to do their job properly, or get
killed by various signals. That's a real benefit to have, and "realler"
than "clean code", so NAK in its current shape and form.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: ae@op5.se