develooper Front page | perl.perl5.porters | Postings from June 2008

Re: IPC::Run [was: This Week on perl5-porters - 1-6 June 2008]

Thread Previous | Thread Next
John E. Malmberg
June 19, 2008 07:01
Re: IPC::Run [was: This Week on perl5-porters - 1-6 June 2008]
Message ID:
Nicholas Clark wrote:
 > On Wed, Jun 18, 2008 at 10:08:03PM -0500, Craig A. Berry wrote:
 >> On Tue, Jun 17, 2008 at 8:42 PM, Jan Dubois <> 
 >>> On Tue, 17 Jun 2008, Barrie Slaymaker wrote:
 >>>> Are Win32 pipes select()able now, in modern Windows and/or perls?
 >>> No, they are not, and I assume never will be.
 >> select() only works on sockets on VMS as well.  It's occasionally
 >> come up that they might make it work on other kinds of filehandles
 >> eventually, but so far haven't.
 > We could make it work on pipes by using the TCP socketpair
 > implementation in util.c. But if I remember what was said earlier
 > about Win32, that would add the bug to pipe that sockets there
 > have - data written to a socket (and hence "pipe") in a
 > process that exits without an explicit close will be lost.

The socketpair implementation is only available for VMS 8.2 and later.

VMS also has the concept of writing an End of File record to a pipe.

 > Heck, can't we *fix* the socket bug in Win32 by simply closing all the
 > PerlIO*s associated with sockets in perl_destruct?

In my port of glib to VMS, there is code to have wrappers to socket() 
and poll() handle terminals, pipes, X11, in addition to handling 
sockets.  A version of that merged into perl would be less complex, and 
is one of the things that I am looking at.

VMS native I/O uses something known as a channel, which is a unsigned 16 
bit token.  This can not be interchanged with a file descriptor, except 
in the case of sockets on the major TCPIP implementations on VMS.

VMS native file I/O uses a pointer to an RMS structure.

In addition, some VMS I/O, such as ICC services uses 32 bit handles for 
tracking connections.  ICC services map well to the UNIX concept of 
named pipes.

Being able to internally store such file handles in a PERL filehandle 
could simplify adding a lot of functionality to Perl on a platform.

Right now, we would have to keep a table of file descriptors that are 
mapped to the native structures to extend Perl.

Such native I/O allows true Asynchronous I/O capabilities on VMS.

Personal Opinion Only

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About