Re: How do I queue perl subroutines to a thread queue instead of data?

[sundialsvc4]

The key design-thought to keep in mind ... in any language, in any situation ... is that “a thread or process is a hamburger cook, not a single hamburger.”   Each thread goes through the same life-cycle as does any cook in a burger-joint:   wait for an order, cook it, deliver it, and then wait for another one.   And, at the end of the shift, he comes out alive.   Maybe he cooked two hamburgers that day ... maybe he cooked a hundred.

Often, threads are specialists ... the “burger-meister,” the “fry guy” and so on.   They sit at one station, and listen to one queue.   Or they can be generalists, all grabbing from one queue and doing whatever comes.   Perl provides plenty of reliable “thread-safe queues,” and even complete workload-management systems like POE.   Your choice.

But, whatever it is, it ought to make sense if mapped to a real-world situation like a fast food restaurant.   Don’t ask the operating system’s thread/process dispatcher to dispatch your application’s work flow, because it can’t.   The so-called “flaming arrow approach” does not work in practice.   A pool of specialized or generalized worker-bees carry out the work, and live to tell the tale.

It is certainly a viable approach to structure the system so that Perl Objects are placed on the queue and the only thing that the worker-bee actually does is to call some execute() method implemented (in the abstract ...) by the base class.