c - Confusion with dup2(), exec() and pipes -


i have been struggling understand concept involving commands dup2(), exec() , pipes in conjunction.

the thing trying achieve:

pipe output of program x input of program y.

something basic who | sort

with parent , 2 children, children responsible executing programs , parent passing programs children.

here don't understand pipes:

p1) pipes treated files , should unidirectional, prevents me using 1 pipe multiple unidirectional communication channels ? so, let's have pipe1 , 3 processes (p - parent - c1, c2, children) have pipe open forking. of these processes use file descriptors. let's assume doing correctly, closing unused pipe ends, p writes c1. what issue using pipe communication between c1 , c2again? while writing question, idea hit me: there issue reads while many processes may have open simultaneously (two processes blocking read), i.e. system cannot sure wants read buffered data written it? if so, how implemented in system ?

i try understand concept, please bear me.

to apply question real life here pseudocode dealing with:

p:

  • p closes unneeded read end of pipe1
  • p sends program argument ('who') c1 via pipe1
  • p closes write end
  • p waits children exit

c1:

  • c1 reads argument read end of pipe1
  • c1 dup2()s standard out write end of pipe1
  • c1 closes both ends of pipe1 (because duped already)
  • c1 execvp()s program ('who')

c2:

  • c2 dup2()s read end of pipe1 stdin gets input program executed
  • c2 closes both ends of pipe1
  • c2 waits input on stdin of c1 duped pipe1
  • c2 execvp()s program ('sort') input


now, if described above, have no luck. if introduced pipe pipe2 looks this:
p:

  • p closes both ends of unneeded pipe pipe2
  • p closes unneeded read end of pipe1
  • p sends program argument ('who') c1 via pipe1
  • p closes write end
  • p waits children exit

c1:

  • c1 closes read end of pipe2
  • c1 reads argument read end of pipe1
  • c1 dup2()s standard out write end of pipe2
  • c1 closes write end of pipe2
  • c1 closes both ends of pipe1 -- pipe2, pipe1 redundant in child
  • c1 execvp()s program ('who')

c2:

  • c2 dup2()s read end of pipe2 stdin
  • c2 closes both ends of pipe1
  • c2 waits input on stdin of c1 duped pipe2
  • c2 executes program sort input

is assumption correct pipes should not reused in multiple processes because system may not sure whom "serve" ? or there other reason ?

pipes designed one-to-one communication — 1 writer, 1 reader. while there nothing prevents having many readers , writers want, behavior makes not usable, multiple readers:

  • reading pipe destructive operation: each byte sent through pipe read 1 of readers, whoever grabs first. if want broadcast information, need either use different ipc mechanism or explicitly replicate data (like tee command).
  • if there multiple writers, writes interspersed in unpredictable way. guarantee writes of size pipe_buf or less atomic.
  • if number of writers drops zero, reader sees end-of-file condition.

in architecture you're describing, have 2 independent communication channels: p sends who c1, , c1 sends output of running who command c2. in shell script, similar to

echo | { read command; exec command; } | sort 

with echo who executed in original process rather in subshell.

your first proposal doesn't work because there's no way output of p go c1 , output of c1 go c2. it's still same pipe, output of p go c2 , output of c1 go itself, or mixture.


Comments

Popular posts from this blog

asp.net mvc - SSO between MVCForum and Umbraco7 -

Python Tkinter keyboard using bind -

ubuntu - Selenium Node Not Connecting to Hub, Not Opening Port -