home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.27 / text0012.txt < prev    next >
Encoding:
Text File  |  1992-05-20  |  1.2 KB  |  29 lines
  1. Submitted-by: peter@ficc.ferranti.com (peter da silva)
  2.  
  3. Peter Collinson noted in the recent Standards Update that there was
  4. opposition to a standard non-blocking system call interface, on the
  5. grounds that the threads interface provided the same functionality.
  6.  
  7. For the case where threads are implemented in user mode, or as a side
  8. effect of threads, it's likely that most implementations will have
  9. some such facility anyway. Given this, I think it would be highly
  10. desirable to spell out a standard interface, whether or not the facility
  11. itself is mandated.
  12.  
  13. In the past I have seen two families of interfaces to this, either one
  14. of which would be acceptable: In the first, you allocate some sort of
  15. magic token (LUNs, Event Flags, Signal Bits, etc...) from a pool, and
  16. pass them to the asynchronous call interface. You can later test or wait
  17. on these tokens to see if an event has occurred. The other interface is
  18. for the async call to return a token which you can use later, similar to
  19. the way UNIX file handles work.
  20.  
  21. Personally, I prefer the latter interface. It's similar to the existing
  22. UNIX open/read/write setup, and the tokens could even be file descriptors
  23. in some implementations.
  24.  
  25.  
  26.  
  27. Volume-Number: Volume 27, Number 13
  28.  
  29.