dallen16 has asked for the wisdom of the Perl Monks concerning the following question:

So ... either I'm having a brain freeze in my old age... or Win32::Pipe doesn't work as it should (at least as I think it should). I get the same problem using ActiveState Perl 5.8.8 and 5.10 on WinXP and Win2K3...

On the server side, I believe the basic process is supposed to be open named pipe (once only), loop, wait for client connect (blocking), read (and write), disconnect, loop until break condition, after break condition, close pipe. Test server side code is as follows. 

use strict;
use warnings;

use Win32::Pipe;

my $jobPipe = new Win32::Pipe('jobPipe') || die "Can't Create Named Pi
+pe 'jobPipe'\n";

while (1) {
    if (!$jobPipe->Connect()) {
        print "jobPipe connect failed\n";
        last;
    }
    print "client connected\n";
    
    my $line = '';
    
    while (my $buf = $jobPipe->Read()) {
        $line .= $buf;
    }
    print "read '$line' from jobPipe\n";
    
    $jobPipe->Disconnect();
    last if (lc(substr($line,0,4)) eq 'exit');
}

$jobPipe->Close();

exit(0);

[download]

So this works the first time through the loop but the second time "$jobPipe->Connect()" is called, it fails -- when it should wait (block) for another client to open the pipe (right?). Client side code follows. 

use strict;
use warnings;

use Win32::Pipe;

my $jobPipe = new Win32::Pipe("\\\\.\\PIPE\\jobPipe") or die "could no
+t open jobPipe\n";

$jobPipe->Write("Dir *.pm\n");
$jobPipe->Close();


exit(0);

[download]

Many thanks in advance.

Dewey

Replies are listed 'Best First'.
Re: Umm... Win32::Pipe
by jand (Friar) on Oct 08, 2008 at 00:45 UTC
    Looks like the documentation is wrong, or at least misleading. The sample code included in Win32::Pipe seems to call Connect/Disconnect in the client and not the server:

    I've just verified that the included samples work, and that the client can connect multiple times to the server.

[reply]
Re: Umm... Win32::Pipe
by BrowserUk (Patriarch) on Oct 08, 2008 at 01:05 UTC

    I could never make it work either, and I've had a couple of attempts at it. The author never responded to bug reports.

    The module is fundamentally broken anyway as it doesn't provide access to the PeekNamedPipe() api which is absolutely critical to making a pipe server work.

    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.
[reply]
      I'm not the author, but I have the CPAN co-maintainer bit for the module and can publish fixes/updates. So feel free to file bugs / patches to the RT queue for Win32::Pipe.

      I know Dave Roth had at one point an updated version on his own web site, but that version was no longer under the Artistic license, so I wouldn't want to apply those changes to the CPAN version.

      The code is now hosted on Google Code

[reply]

        Frankly, I think it would be easier to start again. This time, ensuring that all the relevant APIs are exposed.

        If you look at the remarks section of ConnectNamedPipe, in particular, the first bit about the GetlastError returns and contrast them with the comment in the existing POD about waiting forever, I think you might begin to see what I mean.

        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.
[reply]
Re: Umm... Win32::Pipe
by Anonymous Monk on Oct 08, 2008 at 00:35 UTC
    Whats the error code/text?
[reply]

      On the server side, the first time through the loop, the call to $jobPipe->Connect(); blocks like it's supposed to... waiting for a client to open the named pipe. The first client opens its side of the pipe, writes something, closes it's side of the pipe. The server side connects, reads the data, and then does a disconnect ($jobPipe->Disconnect();). So far so good..

      The problem occurs at the top of the loop, second time through. The second call to $jobPipe->Connect(); doesn't block waiting for a new client to connect. It fails. It's not supposed to fail. It's supposed to block waiting for another client to connect -- just like the first time through. Isn't it?

      Dewey

[reply]
[d/l]
[select]
        Hmm, so whats the error code/text? Better check.
[reply]

Back to Seekers of Perl Wisdom