Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

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

by DeadPoet (Scribe)
on Jan 09, 2011 at 19:35 UTC ( #881366=note: print w/ replies, xml ) Need Help??


in reply to Re^5: RFC: Using 'threads' common aspects
in thread RFC: Using 'threads' common aspects

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


Comment on Re^6: RFC: Using 'threads' common aspects
Download Code
Re^7: RFC: Using 'threads' common aspects
by BrowserUk (Pope) on Jan 09, 2011 at 19:51 UTC
    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?

    None of this was mentioned in either of your two threads. You offered this as an RFC:tutorial, not a chopped down version of a real application with an onerous set of very specific (and till now, unmentioned) technical requirements.

    I hope you realise that I cannot read your mind.

    I also think you may be missing the importance of ensuring that bad process do not remain in the process table.

    In my sample, I only attempted to meet the functionality of your latest code. Your latest code dropped the timeout and kill the process part, so I didn't implement it.

    But adding that functionality back to my sample code would require maybe 5 more lines. (For *nix, maybe 10 for Win32.)


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      BrowserUK I must admit very succinct code and definitely provides me with a different method to view this endeavour.

      In the original post, I did provide a copious amount of code documentation, and was immediately shot down with flames in trail. I understand that that there are those that care little for code comments. Moreover, I have also read your write-up related to documentation--which I mainly disagree. However, that is my perspective, and I do not impose my style on others.

      This is exactly why I removed nearly all comments in secondary postings. But, this did seem to create a breakdown in the conversation, and that is definitely mine to own.

      The topic that I would like to address is not to solve a specific engineering problem, but to aid others that deal with common system administration style tasks. Such tasks normally cover hundreds, if not thousands, of servers of all operating system flavours and states. So, the criteria that I established for myself was:

      * Create a script to leverage Perl 'threads'

      * Display functionality that uses a pool of common threads to perform a series of tasks.

      * Display functionality that runs external commands with timed limitations.

      * Display functionality that will terminate external commands, but does not kill the thread stack.

      * Display functionality that allows for the sharing of data and reporting of collected information.

      Although each of these items were address with the initial functionality of this posting, it was not addresses in the most optimal manner. Evaluating your design, I agree that is highly efficient and effective. Moreover, its memory footprint is about 1/3 the size of mine--very nice indeed.

      Finally, I never intended for you to write for me. However, you did teach to me. I still wish to pursue a composite example for others to leverage as an example of using the common aspect of Perl threads. I honestly believe that such an example should not leverage modules which do-it-for-you because I feel that the learning, if not the understanding, is lost.

      --Poet

        <!-- Discuss how written instructions need to be done to be clear. --> Written language needs to be terse to be clear. <!-- Duplication is bad --> Duplicating ideas or needlessly repeating concepts or even exact language does not clarify. <!-- Duplication muddies. --> It muddies.

        <!-- What about programming? --> This is especially true in programming. <!-- Clarify why. --> A program is a set of instructions. Needless division and duplication in instructions is obviously a problem. The hacker reading the code is parsing it in his <!-- Be gender neutral. --> or her head. With clear, well modularized code this isn't hard for a good hacker but it requires focus. <!-- It can be made hard though. Here's how: --> It's not hard until distractions and noise are introduced. This divides the attention constantly by giving emphasis <!-- EMPHASIS! --> to meaningless echoes.

        <!-- Define documentation in Perl. -->In Perl, comments are comments. Documentation in Perl is <acronym title="Plain old documentation">pod</acronym> <!-- Plain old documentation -->. <-- Referring to comments as copious documentation is somewhere between misleading and inaccurate. It's only documentation for a hacker who has access to the source code. Even then it has many pitfalls besides the ones demonstrated herein. The next time you want to provide documentation, do it with pod. --> Referring to comments as copious documentation is somewhere between misleading and inaccurate. It's only documentation for a hacker who has access to the source code. Even then it has many pitfalls besides the ones demonstrated herein. The next time you want to provide documentation, do it with pod.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://881366]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (9)
As of 2014-12-26 00:56 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (163 votes), past polls