pipe() function in syscalls.cc

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

pipe() function in syscalls.cc

Steve Lipa
"John W. Eaton" <[hidden email]> wrote:

>Why do you need the number?  It's probably best to just pretend that
>the octave_file object is special and just pass it around to functions
>that expect to handle file objects (fprintf, fscanf, fread, etc.).
>
>But, if you really need it, if a file object is used in numeric
>contexts, it is automatically converted to a number, so something like
>
>  nth (x, 1) + 0
>
>should do what you want (but I would still like to know why you need
>to have the number -- maybe it would be useful to have a fileno()
>function).


Dr. Eaton:

Thank you very much for responding to my question.   I want to pipe data
from Octave to a program that allows two forms of interprocess communication:
either a named pipe or an anonymous pipe.   I have been using the named
pipe approach, but I consider it kludgey because I have to have a cleanup
function that deletes the named pipe from the filesystem.

To use the anonymous pipe approach, I need to pass the actual system file
descriptor as a command line argument to the program.  This number happened
to be the same as the file number for simple cases, and everything worked
at first, so I mistakenly thought they were the same or at least related.

It turns out that fid[0] in syscalls.cc consistently contains the correct
descriptor.   My problem was that I was telling the other process to read
from fid[0] and telling Octave to write to fid[1] instead of telling it to
write to the file associated with fid[1].    I simply didn't think hard
enough about the error message which was telling me exactly what I was
doing wrong.

So the end result is that I *do* need to use gpipe.oct because the pipe()
function does not return fid[0].  I don't know how common it is to need the
file descriptor associated with a stream.  I suspect that this application
is rare enough that you don't need to bother with fileno() or filedes()
functions.  

Thank you again for your help!

Steve

--

Steve Lipa
[hidden email]
gpg fingerprint = 8B68 77D7 9E09 9991 C97E  25FF 6A12 D2B9 EC7D 66C1


Reply | Threaded
Open this post in threaded view
|

pipe() function in syscalls.cc

John W. Eaton-6
On 11-Oct-2002, Steve Lipa <[hidden email]> wrote:

| It turns out that fid[0] in syscalls.cc consistently contains the correct
| descriptor.   My problem was that I was telling the other process to read
| from fid[0] and telling Octave to write to fid[1] instead of telling it to
| write to the file associated with fid[1].    I simply didn't think hard
| enough about the error message which was telling me exactly what I was
| doing wrong.

Right, I don't think there is any guarantee that the file id number
Octave uses will match the Unix file descriptor number (if there even
is one on your system -- what would Windows do?).  Octave uses the C++
I/O library, so I don't think there is any standard way to extract a
file number from an iostream object.  So I could provide a fileno
function that would return Octave's file id number, but it would
probably just cause more confusion since the numbers it returns may
not match up with the OS file descriptors.

jwe