home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / unix / question / 9475 < prev    next >
Encoding:
Internet Message Format  |  1992-07-28  |  1.7 KB
  1. Path: sparky!uunet!mcsun!Germany.EU.net!unido!inasys!behe
  2. From: behe@inasys.UUCP (Bernd Hentig)
  3. Newsgroups: comp.unix.questions
  4. Subject: named pipe writer's end problem
  5. Message-ID: <2293@inasys.UUCP>
  6. Date: 28 Jul 92 08:09:54 GMT
  7. Distribution: comp
  8. Organization: inasys GmbH, Bonn, Germany
  9. Lines: 37
  10.  
  11. Systems:    ISC 3.x     
  12. Compiler:   gcc2.2.2    
  13. Hello,
  14. I've got two processes S (server) and C (client).
  15. Process S creates a named pipe P and opens it in mode RD_ONLY.
  16.  
  17. Process C opens the pipe P in mode WR_ONLY after process S
  18. is blocking on the open.
  19. Now C sends 10 messages to S via my own protocol layer,
  20. using select() and read() to get the message and write() to
  21. send the message.
  22.  
  23. Then S (the reader) closes it's end of the pipe and C goes into
  24. a blocking select() call with the pipe descriptor set in the
  25. exceptional descriptor set.
  26.  
  27. Question: If C does never write to this pipe again, how does it
  28. get notified of the closed pipe ???
  29. I do not get a SIGPIPE signal or an exceptional event as I expected
  30. and I do not want to use an additional server pipe that closes on read.
  31.  
  32. If C closes the pipe before S, everything is o.k., the read gets
  33. 0 (EOF) as expected after the select() marked the pipe for reading.
  34.  
  35. Is there anything I am not aware of (fnctl flags, ioctl, etc.) ?
  36. Can I use the select() call to wait on the write pipe when it's still
  37. open and then fails if it gets closed ?
  38. I didn't find any clues in Stevens Network Programming except using
  39. bidirectional pipes (spipe()) which are not what I want because
  40. they are much slower than real pipes (spipes are using streams, which
  41. are really painful for fast communications).
  42.  
  43. Thanx for any suggestions (will post a summary, so you don't need to
  44. crowd comp.unix.questions ... what a horror ...)
  45. Bernd
  46.  
  47.  
  48.