1

When using pipes to communicate between processes under Linux, is there any benefit to creating streams from the pipes using fdopen and then using fread/fwrite on the streams instead of read/write?

Ton van den Heuvel
  • 10,157
  • 6
  • 43
  • 82

3 Answers3

0

Standard Input/Output (stdio)

fdopen is part of the stdio library. From stdio manual, you get this:

The standard I/O library provides a simple and efficient buffered stream I/O interface. Input and output is mapped into logical data streams and the physical I/O characteristics are concealed. The functions and macros are listed below; more information is available from the individual man pages.

And then:

The stdio library is a part of the library libc and routines are automatically loaded as needed by the compilers cc(1) and pc(1). The SYNOPSIS sections of the following manual pages indicate which include files are to be used, what the compiler declaration for the function looks like and which external variables are of interest.

Being part of the libc, it means that programs written using these functions will compile in all standard-conforming compilers. If you write a program using open/write (which are POSIX), then your program will only run on POSIX systems.

So you could reason that (a) it's worth because of portability and (b) it's not worth it if you're only using it in Linux, because then using open/write you remove a whole lot of abstraction (from stdio) - keep in mind that under GNU GLibC open/write are wrappers around the syscalls, you're not actually calling then directly, so a small amount of abstraction is present.

Community
  • 1
  • 1
Enzo Ferber
  • 3,029
  • 1
  • 14
  • 24
0

Writing into a pipe involves a syscall and a context switch. If you would like to minimize these, you may like to use stdio functions to do buffering in the user space, and this also allows for formatted output with fprintf.

Maxim Egorushkin
  • 131,725
  • 17
  • 180
  • 271
-1

A FILE* created out of a file descriptor using fdopen() will provide the additional features of buffering, error checking (feof(), ferror()) etc which you may or may not need. I don't see any benefit of using a fdopen() mainly because the pipe itself will do certain level of buffering (on modern Linux, it's 64K). Besides, in most use-cases where pipes are used in IPC, buffering isn't desirable.

So, I don't see any benefit of using fdopen(). Using read() & write() directly will be sufficient and often desirable in IPC.

P.P
  • 117,907
  • 20
  • 175
  • 238
  • _the pipe itself will do certain level of buffering_ - pipe is a buffer, maintained by the kernel. – Maxim Egorushkin Nov 08 '16 at 10:29
  • The buffering provided by using the `fxxxx` calls happens in the user process, whereas each `write`/`read` requires a system call. The former can be faster in the case of a lot of small writes/reads. – davmac Nov 08 '16 at 10:40
  • @MaximEgorushkin "pipe is a buffer" is misleading. A pipe is a communications channel that _is_ buffered. – davmac Nov 08 '16 at 10:42
  • @davmac Pipe is both or either, depends on the context and the level of detail. – Maxim Egorushkin Nov 08 '16 at 10:43
  • @MaximEgorushkin pipe is *not* a buffer. It definitely has a buffer and is maintained by the kernel. Linux man page states: "Data written to the write end of the pipe is buffered by the kernel until it is read from the read end of the pipe." – P.P Nov 08 '16 at 10:45
  • 1
    @MaximEgorushkin if you insist. The [wikipedia entry](https://en.wikipedia.org/wiki/Anonymous_pipe) says that "an anonymous pipe is a simplex FIFO communication channel that may be used for one-way interprocess communication (IPC)". Personally I think this is the essence of what "pipe" means and that any buffering is a secondary matter. – davmac Nov 08 '16 at 10:46