Take the win32::Pipe module for Perl, available from at least 3 sources: ActiveState, CPAN and its author.
I can vouch that the module does permit creating a Win32 named pipe at a server end and writing to the pipe from the client end. Then the time comes to disconnect.
The docs claim that $Pipe001->Disconnect() will return 1 or 0 depending on if it succeeds or fails.
But a tell-tale sign: in the docs 'working' example, no value is assigned and tested upon Disconnect(). Nor is this done in the 'test' app available from the module's author. And in the docs, the result of a data read (!) is used to close the pipe, i.e.,
$Data = $Pipe->Read();which is a long-standing error in the 'working' example.
$Data->Close()
This is what a current ActiveState Perl in fact reports as the result of $Pipe->Disconnect() with a pipe created, connected, written and read using the Win32::Pipe module
Disconnection result: usage: Disconnect($PipeHandle [, $iPurge]);
Having tried several variants with no success, this remains: you close the pipe ( it will report 0 for that op ) and then you recreate the pipe de novo and wait for another client with Pipe->Connect()
The worry might be what security holes may be opened by the use of this faulty module.
Caveat emptor, err, there is no such thing as free money - except in spam.
Oh, the docs are ambiguous on the key op: destroy. Is it only the 'instance' of the pipe that Disconnect() was to destroy and the pipe 'itself' which Close() was to destroy? And just what is the issue when the client drops off either with or without closing? ( the docs warn that if the client drops before the server, then the server will have a long wait. I found this issue trivial to address with a friendly client of my own devising ... unfriendlies are, well, unfriendly.)
The fact that ActiveState reproduces the author's docs with no clear caveat of their own is somewhat vexing.
