Re^2: Non-blocking Reads from Pipe Filehandle

[cbudin]

Thank you for your insightful and comprehensive reply! I've tried out your test script on my system and it works great, and I think that I will try to incorporate the concepts that it illustrates. I'm not familiar with the threads package, but I will read up on it.

One question, just for clarification: the $pipe variable declared in the pipeCommand() subroutine is different from the $pipe variable created in the main body of the code, correct?

You have convinced me that threads is the way to go in this situation.

cbudin

[BrowserUk]

Thank you for your insightful and comprehensive reply! .... I'm not familiar with the threads package, but I will read up on it.

Your welcome.

Be careful what you read, look carefully at any dates and/or version numbers. threads had a pretty traumatic birth and was for a long time unstable and definitely not for use in production environments. Anything you read relating to threads prior to perl 5.8.4 will probably reflect that.

Actually, for this kind of do-this-blocking-operation-but-don't-make-me-wait, they worked pretty well even before then. Many of the bugs in 5.8.2 & 5.8.3 seemed to be as much to do with closures as it do with threading--and closures can still cause the occasional problem in non-threaded code--but threadind and shared variable cloning conspired to exaserbate those problems.

In my opinion, they have been stable enough for use since 5.8.4. Of course, no one is guarenteeing them totally bug free, but then bugs occasionally turn up in the regex engine, and Math::Big* packages, and perlIO and almost any other area of perl you care to name. Few people would suggest that the 1000's of pieces of code using those facilities should be taken out of production, pending guarentees about the bug-free nature.

the $pipe variable declared in the pipeCommand() subroutine is different from the $pipe variable created in the main body of the code,

Physically, yes.

Different scopes (the mys), different types--one is a filehandle, the other actually a blessed reference to a Thread::Queue object--and they actually exist in different threads.

Conceptually, maybe not.

At the inner level, the filehandle $pipe, is the source of input from the anonymous pipe. Ie. the output from the command.

At the outer level, the queue object $pipe, is the source of input from the anonymous pipe. Ie. the output from the command.

Under the scrutiny of your peer review would I change one of them? Yes, probably. The inner would probably be changed to $pipeFH.

But then, the odds are that you prefer lower_with_underscore indentifiers to CamelCase, so you'll probably change all the names anyway.

You might also feel that the name of the subroutine should reflect the nature of what's inside it more. Maybe something like pipe_asych_command_via_shared_queue().

Or maybe, you feel that the mechanisms don't matter at the outer level and should be encapsulated. Hence a better names might be

my $cmdOutput = openCommandAsInput( )
...
if( $cmdOutput->pending ) {
    my $line = $cmdPutput->dequeue() or last;
    ...

Then again, the existing method names tend to reflect the queue-ish nature of the ITC mechanism, and at the level of use, they could be a distraction. Hence, for your application it might be better to wrap the whole thing into an object and alias the method names with more familiar concepts

my $cmd_fh = open_pipe_command( $cmd );
...
if( $cmd_fh->can_read ) {
    my $line = $cmd_fh->readline or last;
    ...