drs@cerc.wvu.wvnet.edu (Darrell Schiebel) (07/29/89)
I have been attempting to write software utilizing named pipes on
several hardware platforms. The same code seems to behave differently
on each different platform.
Sun (SunOS Release 4.0):
mknod works fine
read blocks
Silicon Graphics (Iris 4D1-3.1D IP6):
mknod works fine
read does not block
DEC (Ultrix-32 V3.0):
mknod works fine
open fails with error "No such device or address" (ERRNO: 6)
HP (HP-UX):
mknod fails with error "Invalid argument" (ERRNO: 22)
Does anyone have any suggestions on how to make this portable ?
Or an alternative to named pipes which is portable?
Here is the code snippet:
#include <errno.h>
#ifdef ULTRIX
#include <fcntl.h>
#else
#include <sys/fcntl.h>
#endif
#define FIFONAME "myfifo"
#define PERMS 0000666
#define FIFO 0010000 /* = S_IFIFO */
main(){
char buffer[200];
int pipe;
if (mknod(FIFONAME, FIFO | PERMS, 0) == -1) {
printf("ERRNO: %d\n",errno);
perror("writer: mknod failed");
exit(1);}
else printf("myfifo created\n");
if ((pipe = open(FIFONAME,O_RDWR)) == -1){
printf("ERRNO: %d\n",errno);
perror("Open Failed");
exit(1);}
if (read(pipe, buffer, 20)< 0){
printf("ERRNO: %d\n",errno);
perror("Read Failed");}}
Any Responses Would be Appreciated.
Darrell Schiebel
--------------------------------------
Concurrent Engineering Research Center
West Virginia University
drs@cerc.wvu.wvnet.edu
drs@g.cs.wvu.wvnet.edu
drs@baks.comguy@auspex.auspex.com (Guy Harris) (07/29/89)
>Does anyone have any suggestions on how to make this portable ?
Well, the "mknod" is a perfectly legitimate call, according to the SVID
(all of the vendors are presumably at least trying to follow the SVID
there, although ultimately they'll all go with POSIX and support
"mkfifo()" also), so the HP implementation is buggy.
The "open" call passes O_RDWR, and the SVID doesn't say anything about
opening a FIFO with that mode, so the DEC implementation is OK according
to the SVID and POSIX (POSIX quite explicitly says the behavior when
O_RDWR is passed is undefined), although it might have been nice had
they made it work (ENXIO is kind of a rude error to return on that), and
made it work the way they do in S5....
Given that the "open"'s behavior isn't specified by the SVID, the
"read"s behavior can't be specified either, although again it might have
been nice had SGI made it work the way it appears to work in the
S5 code - i.e., the "read" blocks, since somebody has the pipe open for
writing but no data's been written but unread....
I'd suggest *not* opening it for reading and writing, but instead open
it for reading and separately open it for writing (presumably, the whole
point of the exercise is to have two unrelated processes communicate, so
one would open it for reading and another would open it for writing).
That might stand a better chance of working on the DEC and SGI systems.
Unfortunately, that still doesn't help with the HP system, so yell at
HP....decot@hpisod2.HP.COM (Dave Decot) (08/01/89)
> Sun (SunOS Release 4.0): > mknod works fine > read blocks > Silicon Graphics (Iris 4D1-3.1D IP6): > mknod works fine > read does not block > DEC (Ultrix-32 V3.0): > mknod works fine > open fails with error "No such device or address" (ERRNO: 6) > HP (HP-UX): > mknod fails with error "Invalid argument" (ERRNO: 22) > > Does anyone have any suggestions on how to make this portable ? > Or an alternative to named pipes which is portable? The posted code works fine on all HP-UX systems I've tried: HP 9000 Series 300 (HP-UX 6.2) mknod works fine read blocks HP 9000 Series 300 (HP-UX 6.5) mknod works fine read blocks HP 9000 Series 800 (HP-UX 3.1) mknod works fine read blocks What release were you using? Note, though, that the use of the constant 0010000 is not guaranteed to be portable; you should really be using the macro S_IFIFO from <sys/stat.h> instead. HP-UX 7.0 (for all HP-UX systems) will support the mkfifo() function. Dave Decot Hewlett-Packard
drs@cerc.wvu.wvnet.edu (Darrell Schiebel) (08/01/89)
In article <14020069@hpisod2.HP.COM>, decot@hpisod2.HP.COM (Dave Decot) writes: > HP 9000 Series 800 (HP-UX 3.1) > mknod works fine > read blocks > > What release were you using? Here is the Release and The Run of the Code as Posted HP-UX holly A.B3.01 B 9000/835 Welcome to HP-UX on the Series 800. [HP Release A.B3.00.5B] hp: hpnod ERRNO: 22 writer: mknod failed: Invalid argument > Note, though, that the use of the constant 0010000 is not guaranteed to > be portable; you should really be using the macro S_IFIFO from > <sys/stat.h> instead. I agree, but I wanted to make sure everything was correct, which is the reason the constant 0010000 was used. The code (including constant definition) was taken directly from an example program in an HP manual (then altered for debugging). (HP 9000 Series 800: Programmer Series; Real-Time Programming Manual. Manual Part #: 92453-90003, Page: 10-11) Darrell Schiebel Concurrent Engineering Research Center drs@cerc.wvu.wvnet.edu
frank@croton.dec.com (Frank Wortner) (08/01/89)
In article <178@cerc.wvu.wvnet.edu.edu>, drs@cerc.wvu.wvnet.edu (Darrell Schiebel) writes:
= I have been attempting to write software utilizing named pipes on
= several hardware platforms. The same code seems to behave differently
= on each different platform.
=
= Sun (SunOS Release 4.0):
= mknod works fine
= read blocks
= Silicon Graphics (Iris 4D1-3.1D IP6):
= mknod works fine
= read does not block
= DEC (Ultrix-32 V3.0):
= mknod works fine
= open fails with error "No such device or address" (ERRNO: 6)
= HP (HP-UX):
= mknod fails with error "Invalid argument" (ERRNO: 22)
I tried Darrell's example on a VAXstation II running UWS 2.0 (== Ultrix 3.0)
and a DECstation 3100 running UWS 2.1 (== Ultrix 3.1), and I could not
reproduce his results.
I get:
DEC (Ultrix-32 3.0/VAX and 3.1/RISC):
mknod works fine
read blocks
Frankdrs@cerc.wvu.wvnet.edu (Darrell Schiebel) (08/02/89)
In article <1419@riscy.dec.com>, frank@croton.dec.com (Frank Wortner) writes: > > In article <178@cerc.wvu.wvnet.edu.edu>, drs@cerc.wvu.wvnet.edu (Darrell Schiebel) writes: > = DEC (Ultrix-32 V3.0): > = mknod works fine > = open fails with error "No such device or address" (ERRNO: 6) ... > I tried Darrell's example on a VAXstation II running UWS 2.0 (== Ultrix 3.0) > and a DECstation 3100 running UWS 2.1 (== Ultrix 3.1), and I could not > reproduce his results. > > I get: > > DEC (Ultrix-32 3.0/VAX and 3.1/RISC): > mknod works fine > read blocks What follow is from a script file of a run of the code posted. I have no idea what the difference is but it seems to indicate a difference in Ultrix Versions. Any suggestions ? Ultrix-32 V3.0 (Rev 64) System #2: Sat Apr 15 12:47:39 EDT 1989 dec: decnod myfifo created ERRNO: 6 Open Failed: No such device or address dec: ls -l myfifo crw-r--r-- 1 drs 255, 255 Aug 1 16:54 myfifo Darrell Schiebel drs@cerc.wvu.wvnet.edu
frank@croton.dec.com (Frank Wortner) (08/02/89)
In article <181@cerc.wvu.wvnet.edu.edu>, drs@cerc.wvu.wvnet.edu (Darrell Schiebel) writes: [Regarding my attempts to duplicate his mknod problem ...] > What follow is from a script file of a run of the code posted. I have no > idea what the difference is but it seems to indicate a difference in Ultrix > Versions. Any suggestions ? > > Ultrix-32 V3.0 (Rev 64) System #2: Sat Apr 15 12:47:39 EDT 1989 > The login banner on the VAXstation II/GPX I used to try the example program says: Ultrix-32 V3.0 (Rev 64) UWS V2.0 System #2: Fri Jan 13 17:35:56 EST 1989 ^^^^^^^^^^^^^^ I used the same version of Ultrix that you have. As I indicated in my previous article on this subject, UWS 2.0 == Ultrix 3.0. The basic difference is that UWS includes an X11 server and is intended for workstations. If anything, the fact that I got the same results on a VAXstation II/GPX running Ultrix 3.0 and a DECstation 3100 running Ultrix 3.1 indicates that there is no difference between versions in regard to the operation of this program. The program behaved consistantly on both machines. Frank
guy@auspex.auspex.com (Guy Harris) (08/03/89)
>dec: decnod >myfifo created >ERRNO: 6 >Open Failed: No such device or address >dec: ls -l myfifo >crw-r--r-- 1 drs 255, 255 Aug 1 16:54 myfifo That ain't no FIFO, that's a character special file. The "mknod" call in the original posting looked OK, so either there's something funny in that code or there's a bug in Ultrix that causes it to create character special files when you ask it to create FIFOs....
grr@cbmvax.UUCP (George Robbins) (08/03/89)
In article <2320@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: > > >dec: decnod > >myfifo created > >ERRNO: 6 > >Open Failed: No such device or address > >dec: ls -l myfifo > >crw-r--r-- 1 drs 255, 255 Aug 1 16:54 myfifo > > That ain't no FIFO, that's a character special file. The "mknod" call > in the original posting looked OK, so either there's something funny in > that code or there's a bug in Ultrix that causes it to create character > special files when you ask it to create FIFOs.... Righto! A problem was described over in comp.unix.ultrix today with mknod of named pipes on NFS filesystems either being remotely accessed or served by Ultrix 3.X. The pipe nodes are actually created correctly, but Ultrix "sees" them as character special files on a filesystem it has remotely mounted and screws up in other amusing ways when a Sun or other system tries to access a pipe on a remotely mounted filesystem. Hopefully, DEC will fix this. The sample program should work fine on a locally mounted filesystem. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
decot@hpisod2.HP.COM (Dave Decot) (08/04/89)
Apparently, the problem you encountered on the HP-UX system is a limitation in Sun's NFS, which you were not using when you tested the other systems. Prior to NFS version 3.2, NFS did not permit FIFO files to be created on remote NFS-mounted filesystems at all. After NFS version 3.2, FIFO files can be created remotely. The HP-UX release you are using contains a version of NFS prior to 3.2. The next release of HP-UX (7.0) will contain a version of NFS compatible with NFS 3.2 that will permit you to create FIFO files on NFS-mounted file systems. However, note that no version of NFS I know of permits you to actually use a FIFO file to communicate to a process on another processor, since when they are opened, the contents are stored locally. This is yet another small UNIX feature one has to avoid when NFS might be around because of the stateless operation of NFS. DISCLAIMER: My opinions only. I do not speak for HP (or Sun, for that matter). Dave Decot Hewlett-Packard Company hpda!decot
jim@cs.strath.ac.uk (Jim Reid) (08/04/89)
In article <2320@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
# >dec: decnod
# >myfifo created
# >dec: ls -l myfifo
# >crw-r--r-- 1 drs 255, 255 Aug 1 16:54 myfifo
#
#That ain't no FIFO, that's a character special file. The "mknod" call
#in the original posting looked OK, so either there's something funny in
#that code or there's a bug in Ultrix that causes it to create character
#special files when you ask it to create FIFOs....
Or the ULTRIX ls command can't tell the difference between fifos and
character special files....
Jim