home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / fj / maillis / xwindow / 17492 < prev    next >
Encoding:
Internet Message Format  |  1992-11-15  |  2.5 KB
  1. Path: sparky!uunet!spool.mu.edu!darwin.sura.net!sgiblab!nec-gw!nec-tyo!wnoc-tyo-news!scslwide!wsgw!wsservra!daemon
  2. From: matt@centerline.com (Matt Landau)
  3. Newsgroups: fj.mail-lists.x-window
  4. Subject: Re: FLAME, FLAME ON X!!!
  5. Message-ID: <1992Nov16.094034.10647@sm.sony.co.jp>
  6. Date: 16 Nov 92 09:40:34 GMT
  7. Sender: daemon@sm.sony.co.jp (The devil himself)
  8. Distribution: fj
  9. Organization: CenterLine Software, Inc.
  10. Lines: 43
  11. Approved: michael@sm.sony.co.jp
  12.  
  13. Date: 10 Nov 92 00:56:39 GMT
  14. Message-Id: <1dn1c7INNcnp@armory.centerline.com>
  15. Newsgroups: comp.windows.x
  16. References: <1683@igd.fhg.de>, <1992Nov9.235741.25166@dsd.es.com>
  17. Sender: xpert-request@expo.lcs.mit.edu
  18.  
  19. In <1992Nov9.235741.25166@dsd.es.com> pmartz@dsd.es.com (Paul Martz) writes:
  20. >In article <1683@igd.fhg.de>, baumann@igd.fhg.de (Peter Baumann) writes:
  21. >> [ ... ]
  22. >> 
  23. >> Short after that, a colleague of the bad-luck guy occasionally
  24. >> remarked, "Did you know that the X windows server never releases
  25. >> memory space once acquired for image display? Each new image loaded
  26. >> makes the X server address space grow until there's no more available."
  27. >> And added, "This is a well-known bug of X". Well-known. Well...
  28.  
  29. >Care to tell us in which vendor's X is this a bug? I've certainly
  30. >never heard of it before.
  31.  
  32. This sounds like a third-hand version of the oft-heard complaint that 
  33. most X11 servers will never release memory *back to the operating system*;
  34. i.e., that once the X server has allocated a huge chunk of memory for, 
  35. say, an image, that memory will never be made available to any other 
  36. application running on the same system.
  37.  
  38. This is, in fact, generally true, but it has nothing at all to do with
  39. the X server.  It's simply an artifact of the fact that most versions
  40. of *free* don't return memory to the O/S, they simply stick it back on
  41. the free list for subsequent allocation from within the same process.
  42.  
  43. The X server merely exhibits the same behavior as any other program using
  44. the standard malloc/free storage allocator.  It's true, however, that 
  45. such behavior is much more acceptable in programs that run for a while
  46. and then exit than in programs that run forever, like daemons and window
  47. systems.  But it's not really X11's fault, per se.
  48.  
  49. Actually, I once saw a malloc package that could be made to return some
  50. memory to the operating system by clever use of sbrk and brk, but I doubt 
  51. that any X11 servers are written using such a technique.  Might be an
  52. interesting experiment for some vendor, though ...
  53. --
  54.  Matt Landau            Waiting for a flash of enlightenment
  55.  matt@centerline.com              in all this blood and thunder
  56.