Tom Metro wrote: > Roger Heflin wrote: >> Named pipes don't export either... > > Are you sure? This I'm more skeptical of. I'll have to try an experiment > and see what happens when a named pipe is read from via NFS, SMB, and > sshfs. My expectation is that the network file system daemon will pass > on the file I/O operations to the named pipe, and the underlying file > system driver and the kernel will implement the pipe I/O. > > What you say is backed up by this FAQ: > http://www.unixguide.net/unix/programming/2.10.4.shtml > and: > http://developers.sun.com/solaris/articles/named_pipes.html > > but it doesn't give an explanation of why it doesn't work.
I didn't run this experiment, but while researching something related I ran across an explanation that likely applies. This is about UNIX domain sockets, which are likely implemented in the Linux kernel using some of the same plumbing as named pipes. http://stackoverflow.com/questions/783134/af-unix-domain-why-use-local-file-names-only UNIX domain sockets use the file system as address name space... This allows two distinct processes to open the same socket in order to communicate. However, the actual communication (the data exchange) does not use the file system, but buffers in kernel memory. ...the communication between processes is done within the local system and does not result in a seekable file getting stored anywhere. The advantage of using the file system as the namespace for the end-points is that normal file permissions and ACLs can be applied - if you can't open the end-point you can't connect. So the use of the filesystem is misleading with respect to the actual I/O. The file system is merely used as a convenient namespace and authorization mechanism. The kernel must be intercepting the I/O well before any file system driver gets involved. (Presumably it would pass on a stat() or similar call to the file system driver to check permissions.) I guess the UNIX philosophy of making everything look like a file extends only so far. You could extend pipes or sockets across a network with an appropriate shim program (I found, for example, a patched OpenSSH that can extend UNIX domain sockets across a network), but not with a network file system driver. The shim needs to be aware of the specific sockets/pipes that you want to extend. And you'd obviously suffer a substantial performance impact, compared to using shared kernel memory. -Tom ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mvpmc-users mailing list Mvpmc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mvpmc-users mvpmc wiki: http://mvpmc.wikispaces.com/
