home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / mac / programm / 22344 < prev    next >
Encoding:
Text File  |  1993-01-28  |  2.7 KB  |  72 lines
  1. Newsgroups: comp.sys.mac.programmer
  2. Path: sparky!uunet!ferkel.ucsb.edu!taco!rock!stanford.edu!agate!spool.mu.edu!darwin.sura.net!udel!intercon!psinntp!sunic!kth.se!hemul.nada.kth.se!d88-jwa
  3. From: d88-jwa@hemul.nada.kth.se (Jon WΣtte)
  4. Subject: Re: A malloc() built upon sbrk() on a Mac?
  5. Message-ID: <1993Jan27.164137.29669@kth.se>
  6. Sender: usenet@kth.se (Usenet)
  7. Nntp-Posting-Host: hemul.nada.kth.se
  8. Organization: Royal Institute of Technology, Stockholm, Sweden
  9. References: <BOORTZ.93Jan27115728@dunlop.sics.se>
  10. Distribution: comp
  11. Date: Wed, 27 Jan 1993 16:41:37 GMT
  12. Lines: 58
  13.  
  14. In <BOORTZ.93Jan27115728@dunlop.sics.se> boortz@sics.se (Kent Boortz) writes:
  15.  
  16. >1.    Allocate a fixed stack space (this is the normal way
  17. >    on a Mac, isn't it?)
  18.  
  19. Yes. It is defaulted at 8k/24k depending on your machine.
  20.  
  21. >2.    Allocate with NewPtr() memory at the lowest address
  22. >    in the application heap. This will be immediately
  23. >    after the stack space.
  24.  
  25. Tut-tut. The stack grows from top down to the heap limit.
  26. Pointers are shoved as far down as possible in the heap. In
  27. between lies handles that can move. MoveHHi tries to slam
  28. its argument handle to the top of the heap.
  29.  
  30. >3.    Implement sbrk() with SetPtrSize() on this memory area
  31. >    and let malloc() take memory from this area.
  32.  
  33. Bad Idea. SetPtrSize may move the block, which invalidates all
  34. your present pointers into it. Not to mention there might be another
  35. locked block (ptr or locked handle that isn┤t movehhid) in its way.
  36.  
  37. >4.    If SetPtrSize() fails I do a MaxApplZone() and try
  38. >    again.
  39.  
  40. Won┤t help; SetPtrSize WILL call MaxApplZone() and try again.
  41. Not to mention you should call it right after setting the amount
  42. of stack you need yourself, BEFORE calling InitGraf.
  43.  
  44. >Any thought about this? Is there other ways of doing what I want?
  45.  
  46. Grab all of the available memory minus a constant (for code
  47. resources etc) and a percentage (so increasing app heap size
  48. helps for the users)
  49.  
  50. The keep your own sbrk() pointer that you just walk through your
  51. existing block. There is no better way.
  52.  
  53. >Is there any way of doing mmap() on a mac? I have some large allocated
  54. >blocks that sometimes has to grow, and many small blocks. This sometimes
  55. >lead to big holes in the malloc memory area. If I could place these blocks
  56. >sparse they could grow and shrink without moving.
  57.  
  58. Instead, use handles, and re-code your application to take advantage
  59. of this. Handles can grow completely independently of each other
  60. (well, almost) as long as you don't lock them. You have to be
  61. careful about locking down handles whenever you pass its dereference,
  62. or something derived from this reference, to the ToolBox.
  63.  
  64. Cheers,
  65.  
  66.                         / h+
  67. -- 
  68.  -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe --
  69.  
  70.    What we need is a good GNU [...] licence manager implementation.
  71.                      -- Raphael Manfredi
  72.