home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / unix / internal / 1587 < prev    next >
Encoding:
Text File  |  1992-07-22  |  2.1 KB  |  49 lines
  1. Newsgroups: comp.unix.internals
  2. Path: sparky!uunet!decwrl!pa.dec.com!rdg.dec.com!narcy.gao.dec.com!jfoy
  3. From: jfoy@narcy.gao.dec.com (John Foy)
  4. Subject: Re: Multiple listeners on same socket
  5. Message-ID: <1992Jul23.084108.22337@rdg.dec.com>
  6. Lines: 36
  7. Sender: news@rdg.dec.com (Mr News)
  8. Reply-To: jfoy@narcy.gao.dec.com (John Foy)
  9. Organization: Digital Equipment Corporation
  10. References:  <1992Jul22.034730.12159@menudo.uh.edu>
  11. Date: Thu, 23 Jul 1992 08:41:08 GMT
  12.  
  13.  
  14. In article <1992Jul22.034730.12159@menudo.uh.edu>, nagappa@menudo.uh.edu (Chaitanya Nagappa) writes:
  15. |>From: nagappa@menudo.uh.edu (Chaitanya Nagappa)
  16. |>Newsgroups: comp.unix.internals
  17. |>Subject: Multiple listeners on same socket
  18. |>
  19. |>The following is posted for a friend of mine.
  20. |>-C. Nagappa.
  21. |>
  22. |>==============================================================================
  23. |>Howdy all,
  24. |>I need something equivalent to a socket, but that more than one process
  25. |>can listen on. This is for multiple consumers, and the output from the
  26. |>server can be picked up by any one of the consumers. In the simplest
  27. |>scenario, I have two processes doing a "listen" on the same socket,
  28. |>and only one of these process is trigerred to establish the circuit.
  29. |>Yes, I know neither BSD sockets or TLI can do this. What is then the
  30. |>alternative? Do I have to create my own virtual device?
  31. |>
  32. |>Message queues & FIFOs are not a viable alternative, as the information
  33. |>once placed cannot be ...
  34. |>[...]
  35. |>The problem of statically placing this using standard IPC methods such as
  36. |>message queues, FIFOs or shared memory is that by the time my processes
  37. |>get around to receiving the info. (worst case scenario) the call might
  38. |>have been cleared. So I need a phased communication of the info.
  39.  
  40. I'm not sure what you mean by "phased communcation..."?
  41.  
  42. I'm not entirely familiar with select etc... (being more of a VMS'r) but have
  43. you considered semaphores? e.g. the server pool waits on a counting semaphore
  44. which is incremented by the 'dispatching' process (I think you refer to this as
  45. the 'spawned' process)...? This way only available servers respond...
  46.  
  47.  
  48.     jf
  49.