The assumed benefit is creation of an abstract API.

The problem is, whether you action inputs in the current thread, or in another thread has nothing to do with abstraction: it is an implementation detail.

And abstraction might be something like a subroutine called: enact(). It might be used something like:

while( my $decree = <STDIN> ) {
    chomp $decree;
    enact( $decree );
}
[download]

You can now implement enact() is any number of ways: as immediate code as an if/elsif/else cascade, or a dispatch table; or passing the responsibility off to a concurrent thread or process via a queue, pipe, socket or shared memory. Whatever.

But as currently coded, there is no abstraction. (Other than the use of a queue and another thread, and they add complexity rather than hide it!) And you are gaining no benefit from the use of concurrency. It will take at least 2 context switches to go from reading an input to the point of having enacted it. And a context switch will take 2 or 3 orders of magnitude longer (x100 or x1000) than processing the input inline.

All you've achieved by multithreading that data path, is to use more memory and make things slower. Now given that all of the inputs you've outlined can be processed far more quickly than a human being can type the next command, there is no benefit there either. You would only benefit if the inputs were being supplied by another program or computer faster than you could process them inline. And even then, unless the input stream was bursty, all you would do is fill up the queue with commands faster than you could take them off and process them.

Voltaire (apparently) said: a book is not finished when you can add no more, but rather when you can remove no more. And nothing is a more laudable and beneficial goal in code development, than removing anything that serves no purpose.

I think I follow your arguments here and appreciate their content. By using a direct function call, I can maintain the same level of abstraction (even to the point of not modifying the format of my messages as they are today, if I so desired) without the added complexity and performance penalties that a separate minister thread would incur. If I needed some level of persistence (in this case, the thread and semaphore hashes), that could be created using module variables.

This raises a question for me about output. In this scenario, I can rationalize the use of an outbox queue since I have results coming in from multiple sources that then need to be pushed in some manner to the interface. However, I also see that my appreciation of the use of threaded tools is not yet mature (kid with a new toy). As I see it, it would be a good idea to keep the worker threads isolated to their tasks and use of a dispatch table would cause their threads of control to get caught up in the interface. Does this make sense, or am I missing the big picture again?

Thank you for your time, patience and wisdom for helping me on my pilgrimage toward enlightenment.