Will start by saying that this is more philosophical than code/pseudo-code. I'm also in the "early stages" of learning threads with Perl. Have written a couple threaded apps for file operations, but now looking to expand that knowledge.
After many hours of searching, reading and trying to establish "an optimal method" - looking for opinion/guidance/suggestion/etc.
Suspect Boss/Worker(s) is the correct solution for my paradigm
Based on Boss/Worker, the items below expresses "desirable" end-state.
Queues via Thread::Queue
Waits for <STDIN>
Appends manipulated input to $TXQUEUE->enqueue()
Monitor $RXQUEUE and <STDIN> - simultaneously???
Sends <STDOUT> while(my $RESULT=$RXQUEUE->dequeue_nb()), until $RXQUEUE is empty. $RESULT is sent "AS-IS"
Obtain next queue item from $TXQUEUE->dequeue_nb()
Interact with data engines to derive answer
Append result(s) to $RXQUEUE->enqueue()
Right now to bridge the gap, there may be as many as 50 instances of this "middleware" between the data engines and the application.
Each middleware instance (upon instantiation) creates connections to the data engines, for the life of the process, to avoid connection overhead.
Currently using a while(my $INPUT=<STDIN>) - it's simple text artifacts being prefaced by a transaction ID.
At the moment, the transaction rate can vary from zero to +/- 50 at any given moment. May go minutes without a transaction or may sustain an average between 30-42 per second for 45-90 seconds.
Does not run and exit. Kept open by application, until application is shutdown
Most examples seen appear to be something that passes the socket to worker to complete vs. activity to worker and then obtain worker result to provide response -or- appear to run until complete and exit vs. keeping thread(s) idle/monitoring for next transaction(s). (May have missed a superb example out there?)
Have seen a lot of posts about not using Perl library 'X' for pools/etc. For 5.24 (or better) is that still the prevailing perspective? (eg: no better mouse trap)
Have seen the use of "usleep", is that the best method for "idling" a worker thread?
Is there a way to achieve the benefit of the while loop (avoid CPU cycle consumption while idle), but then issue of providing results to <STDOUT> the moment (or very close to when) they are available?