home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / fj / maillis / xwindow / 17580 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  1.6 KB
  1. Path: sparky!uunet!stanford.edu!sun-barr!sh.wide!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: <1992Nov18.090930.5083@sm.sony.co.jp>
  6. Date: 18 Nov 92 09:09:30 GMT
  7. Sender: daemon@sm.sony.co.jp (The devil himself)
  8. Distribution: fj
  9. Organization: CenterLine Software, Inc.
  10. Lines: 21
  11. Approved: michael@sm.sony.co.jp
  12.  
  13. Date: 10 Nov 92 18:28:15 GMT
  14. Message-Id: <1douvvINNe8a@armory.centerline.com>
  15. Newsgroups: comp.windows.x
  16. References: <1992Nov9.235741.25166@dsd.es.com>, <1dn1c7INNcnp@armory.centerline.com>, <1992Nov10.173203.10719@dsd.es.com>
  17. Sender: xpert-request@expo.lcs.mit.edu
  18.  
  19. In <1992Nov10.173203.10719@dsd.es.com> pmartz@dsd.es.com (Paul Martz) writes:
  20. >Yes but this doesn't sound like what the guy's describing. If this is
  21. >just free() only freeing memory back to the process, then starting the
  22. >same X client over again and walking it through the same sequence of
  23. >tasks should not cause the server process size to grow, because the
  24. >memory it freed before is still available to it.
  25.  
  26. I think this depends on what happens between invocations of the client.  
  27. Depending on what other clients are running and what requests are being 
  28. made of the server, it seems possible that the large contiguous blocks 
  29. or memory previously used for displaying large pixmaps might be partially 
  30. or wholly reallocated to other clients, and that the resulting memory
  31. fragmentation would require malloc(some-large-size) to go back to the
  32. operating system for more memory if no suitably large block remained
  33. on the free list.
  34.