home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / atari / st / tech / 6476 < prev    next >
Encoding:
Internet Message Format  |  1993-01-05  |  1.3 KB
  1. Path: sparky!uunet!munnari.oz.au!metro!socs.uts.edu.au!kralizec.zeta.org.au!ixgate!michael.smith
  2. From: michael.smith@f842.n800.z3.fido.zeta.org.au (michael smith)
  3. Message-ID: <3_800_842_fidonet2b3b73f1@Kralizec.fido.zeta.org.au>
  4. Newsgroups: comp.sys.atari.st.tech
  5. Subject: Re: MiNT, which way forward...
  6. Organization: Fidonet. Gate admin is fido@socs.uts.edu.au
  7. Date: 25 Dec 92 21:46:00 GMT
  8. Lines: 24
  9.  
  10. Original to: nino@vmars.tuwien.ac.at
  11. In a message of <16 Dec 1992 12:16:3>, nino@vmars.tuwien.ac.at (3:713/602)
  12. writes:
  13.  
  14.  n> Speaking of MiNT, has anyone tried to write a Unix-like IPC
  15.  n> library, eg. for arbitrarily sized messages, shared memory
  16.  n> functions etc.? Having considered this for a while, I couldn't
  17.  n> come up with a way to 'wait for messages with IDs from 0 to XX'
  18.  n> except with busy waiting... Will MiNT ever support this, or
  19.  n> has anyone else thought about it?
  20.  
  21. On first blush, I'd say that having the OS keep a list of processes waiting
  22. for messages, and have an upper and lower limit on the source ID wouild do
  23. the trick.  Ie, kernel support.  Thusly, when the message is sent, the
  24. recipient is woken with the data all there & ready.
  25.  
  26. Is my foot bleeding yet?
  27.  
  28.  n> -MY
  29.  
  30. \`miff`                                                       /|\
  31.  
  32. --- ScanMail 0.68 X0501
  33.  * Origin: That Which Is Not, ST in SA. 61-8-232-5722 (3:800/842)
  34.