home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / research / 888 < prev    next >
Encoding:
Internet Message Format  |  1992-09-02  |  1.7 KB
  1. Path: sparky!uunet!olivea!hal.com!darkstar.UCSC.EDU!osr
  2. From: jesup@cbmvax.cbm.commodore.com (Randell Jesup)
  3. Newsgroups: comp.os.research
  4. Subject: Re: Lightweight threads and "real" users
  5. Message-ID: <1833h8INNe57@darkstar.UCSC.EDU>
  6. Date: 2 Sep 92 19:09:28 GMT
  7. References: <13cn3eINN8cn@darkstar.UCSC.EDU> <13sb8pINNn28@darkstar.UCSC.EDU> <17n06qINN793@darkstar.UCSC.EDU> <17tq4mINNfdl@darkstar.UCSC.EDU>
  8. Organization: Commodore, West Chester, PA
  9. Lines: 22
  10. Approved: comp-os-research@ftp.cse.ucsc.edu
  11. NNTP-Posting-Host: ftp.cse.ucsc.edu
  12. Originator: osr@ftp
  13.  
  14. fouts@bozeman.hpl.hp.com (Martin Fouts) writes:
  15. >In article <17n06qINN793@darkstar.UCSC.EDU>, Jack_Palevich@taligent.com (Jack Palevich) writes:
  16. >|> 3) Between address spaces use synchronous send-and-wait-for-reply
  17. >|> messaging, rather than asynch messaging.
  18.  
  19. >If you don't, there will be a class of applications you will be able
  20. >to write more efficiently than otherwise.  The above rules are good
  21. >rules and should be followed unless you can discover a compelling
  22. >reason not to follow them.  The trick here is that the reason must be
  23. >compelling.
  24.  
  25.     I agree, Rule 3 is iffy at best.  Programs that have realtime response
  26. problems would have to hide the synchronicity themselves by spawning even
  27. more threads.  Another good example is an interface manager that sends messages
  28. indicating UI actions that have taken place (such as "he clicked here").  You
  29. _don't_ want the UI manager to block because the program was calculating
  30. an FFT.  This is what gave people so much trouble porting things to the MacOS:
  31. they had to sprinkle GetNextEvent() calls in code that might run for a long
  32. while, to keep the UI running.
  33.  
  34.     I would think that might be rewritten "use synchronous messaging
  35. whenever there isn't a good reason to use async".
  36.