home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / fj / maillis / xwindow / 17490 < prev    next >
Encoding:
Internet Message Format  |  1992-11-15  |  2.1 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: dd@adobe.com (David DiGiacomo)
  3. Newsgroups: fj.mail-lists.x-window
  4. Subject: Re: FLAME, FLAME ON X!!!
  5. Message-ID: <1992Nov16.094002.10550@sm.sony.co.jp>
  6. Date: 16 Nov 92 09:40:02 GMT
  7. Sender: daemon@sm.sony.co.jp (The devil himself)
  8. Distribution: fj
  9. Organization: Adobe Systems Incorporated
  10. Lines: 38
  11. Approved: michael@sm.sony.co.jp
  12.  
  13. Date: 10 Nov 92 00:44:28 GMT
  14. Message-Id: <1992Nov10.004428.17556@adobe.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 article <1992Nov9.235741.25166@dsd.es.com> pmartz@dsd.es.com (Paul
  20. Martz) writes:
  21. >In article <1683@igd.fhg.de>, baumann@igd.fhg.de (Peter Baumann) writes:
  22. >> [ ... ]
  23. >> 
  24. >> Short after that, a colleague of the bad-luck guy occasionally
  25. >> remarked, "Did you know that the X windows server never releases
  26. >> memory space once acquired for image display? Each new image loaded
  27. >> makes the X server address space grow until there's no more available."
  28. >> And added, "This is a well-known bug of X". Well-known. Well...
  29. >
  30. >Care to tell us in which vendor's X is this a bug? I've certainly
  31. >never heard of it before.
  32.  
  33. Paul, how disingenous of you.
  34.  
  35. Peter Baumann is obviously referring to a common and unfortunate
  36. situation, in a garbled way.  The MIT sample server allocates and
  37. deallocates pixmaps with C library malloc() and free() calls.  In typical
  38. Unix C library implementations, free() never causes the process address
  39. space to shrink.  Depending on the exact allocation strategy of malloc,
  40. and the intervening client activity, it's quite likely that a client
  41. displaying a series of images will cause the server to grow monotonically.
  42.  
  43. The usual solution to this problem is to modify the server to allocate
  44. pixmaps (or at least large pixmaps) from a separate heap.  If they are
  45. padded to page boundaries it is even possible to attempt to free swap
  46. space on pixmap deallocation, but the effectiveness of this varies among
  47. Unix VM system implementions.
  48.  
  49. --
  50. David DiGiacomo, Adobe Systems, Mountain View, CA  dd@adobe.com
  51.