home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / windows / x / 18967 < prev    next >
Encoding:
Internet Message Format  |  1992-11-10  |  1.4 KB
  1. Path: sparky!uunet!think.com!spool.mu.edu!hri.com!noc.near.net!news.centerline.com!matt
  2. From: matt@centerline.com (Matt Landau)
  3. Newsgroups: comp.windows.x
  4. Subject: Re: FLAME, FLAME ON X!!!
  5. Message-ID: <1douvvINNe8a@armory.centerline.com>
  6. Date: 10 Nov 92 18:28:15 GMT
  7. References: <1683@igd.fhg.de> <1992Nov9.235741.25166@dsd.es.com> <1dn1c7INNcnp@armory.centerline.com> <1992Nov10.173203.10719@dsd.es.com>
  8. Organization: CenterLine Software, Inc.
  9. Lines: 15
  10. NNTP-Posting-Host: 140.239.1.32
  11.  
  12. In <1992Nov10.173203.10719@dsd.es.com> pmartz@dsd.es.com (Paul Martz) writes:
  13. >Yes but this doesn't sound like what the guy's describing. If this is
  14. >just free() only freeing memory back to the process, then starting the
  15. >same X client over again and walking it through the same sequence of
  16. >tasks should not cause the server process size to grow, because the
  17. >memory it freed before is still available to it.
  18.  
  19. I think this depends on what happens between invocations of the client.  
  20. Depending on what other clients are running and what requests are being 
  21. made of the server, it seems possible that the large contiguous blocks 
  22. or memory previously used for displaying large pixmaps might be partially 
  23. or wholly reallocated to other clients, and that the resulting memory
  24. fragmentation would require malloc(some-large-size) to go back to the
  25. operating system for more memory if no suitably large block remained
  26. on the free list.
  27.