home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / windows / x / 19294 < prev    next >
Encoding:
Text File  |  1992-11-18  |  1.3 KB  |  32 lines
  1. Newsgroups: comp.windows.x
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!elroy.jpl.nasa.gov!llyene!thyme!kaleb
  3. From: kaleb@thyme.jpl.nasa.gov (Kaleb Keithley)
  4. Subject: Re: FLAME, FLAME ON X!!!
  5. Message-ID: <1992Nov18.170444.29009@thyme.jpl.nasa.gov>
  6. Organization: Jet Propulsion Laboratory, Pasadena, CA
  7. References: <1992Nov11.152545.1929@westford.ccur.com> <1ebp5cINNp7c@armory.centerline.com>
  8. Date: Wed, 18 Nov 92 17:04:44 GMT
  9. Lines: 21
  10.  
  11. In article jimf@centerline.com (Jim Frost) writes:
  12. >>>Actually, I once saw a malloc package that could be made to return some
  13. >>>memory to the operating system by clever use of sbrk and brk, but I doubt 
  14. >
  15. >I've written such a thing, actually.  It's not particularly difficult
  16. >although it becomes a question of whether it's smarter to do the
  17. >correct brk/sbrk or to hang onto the piece (the brk/sbrk requires a
  18. >system call which you'd prefer to avoid).  I dealt with that issue by
  19. >never doing a negative sbrk unless I had the whole piece that I got
  20. >when I did the positive sbrk, but a threshold is probably a better
  21. >approach.
  22. >
  23.  
  24. But all the world's not a Sun.  I've had people tell me that a negative
  25. value to sbrk on other systems either is ignored or is an error.
  26.  
  27. -- 
  28.  
  29. Kaleb Keithley                          kaleb@thyme.jpl.nasa.gov
  30.  
  31. Not authorized, in any way, shape, or form, to speak for anyone.
  32.