Hi, 

I see the same mistake in this module as in 99% of the modules (including 
mine). Why did you write it, with examples of what was wrong with the other 
modules. I said with examples.

The fathers of the CPAN nation were wise. They advised a "See Also" section 
which should be very detailed since we never, ahem, write anything without 
researching the subject thoroughly.

Were there other modules you could have enhanced?


# causes Illegal seek, but safe to ignore? Euu, well you tell us before you 
release.

Did you run Perl::Critic on it?

IMVHO, because formatting issues are so not interesting, 

my $self = shift;
my $name = shift;

is much better written

my ($self, $name) = @_ ;


sub get_names # return array of active processes by name
{
...
    my @ret = []; #NKH, Hu!

You write:
The above example works but does not really demonstrate the full power
of the module. In a more useful implementation (e.g. using
Parallel::Jobs) the parent thread may continuously monitor all workers' 
output and provide management such as spawning new workers or sending 
signals to children by their pid. detach() and forget() could be called
from the run_on_finish() callback of Parallel::Jobs, depending on the 
child's exit status or output.

That paragraph would totally remove any lust I'd have to use the module! If 
you have a better example, give it instead for giving a lower usefulness one. 
Then you go:

Note: only one pipe is created, with a pair of filehandles for uni-
directional communication, i.e. from child to parent. Bidirectional
IPC might be a nice enhancement for this module, or it may be an
indication that a more robust solution, such as POE, is called for.

Hmm, well, IMO, think again about the usefulness of the module and if you 
should put it on CPAN. Frankly, I am not convinced and as you see above, I did 
take some time to look around. Don't get me wrong, The more module authors the 
better. Also, the better the documentation, the more users, the better.

Cheers, Nadim.










Reply via email to