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
| [reply] |
<!-- 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.
| [reply] |
