Re^6: RFC: Using 'threads' common aspects

[DeadPoet]

Wow, a lot to digest....

Let me try to address a couple of your questions.

Let's start with "Why open3?"

Open3 provides me an easily method for splitting IO communication. Most of the stuff I deal with is over SecureShell and frankly I like the way the output is available via the appropriate handles. Moreover, the need to time out a process is highly needed no matter if the command is local or remote. Take the example of the 'df' command and HP-UX, what happens if one run the command and it hits a hung NFS file system? The entire command is now hung thus the thread, and eventually the program. The point is not that one could exclude NFS from the command, but more to the point that the unexpected happens when dealing with 3000 server. Just because one terminates the thread or breaks the pipe does not mean the process will not remain. SecureShell is such a great example of this.

The DEFAULTS, yes I can flag it as READONLY or CONSTANT, it is just a place holder for program defaults. However, if I expanded such a program to leverage getopts to specify maximum, minimum, etc... values the constant/readonly aspect becomes a moot point.

Central printing, just an example... Yes, I totally understand that each thread can manage its own printing aspect with a simple lock variable and that is without a doubt the more efficient manner. Thus, should have been my first choice.

Timestamp(): This is used by the print_manager. In my business, time stamp is everything, but in this example just an indicator of program progress.

sub print_manager {
  lock $l_PRINT;
  while ( ! $f_TERM_PRINT ) {
    usleep(100_000);
    print STDOUT  '[' . timestamp() . ']: '
                  . $q_PRINT->dequeue() . "\n";
  }
  threads->exit();
} ## end print_manager.

For the remaining topics, I need to digest and think about everything. I think I see where you are going, but I also think you may be missing the importance of ensuring that bad process do not remain in the process table.

Once again, I must give thanks for your time and thoughts.

--Poet