home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / atari / st / tech / 6443 < prev    next >
Encoding:
Text File  |  1993-01-02  |  2.1 KB  |  46 lines
  1. Newsgroups: comp.sys.atari.st.tech
  2. Path: sparky!uunet!spool.mu.edu!umn.edu!csus.edu!netcom.com!ersmith
  3. From: ersmith@netcom.com (Eric R. Smith)
  4. Subject: Malloc (Was: Sending objc_draw to a buffer)
  5. Message-ID: <1993Jan3.035343.15539@netcom.com>
  6. Organization: Netcom Online Communications Services (408-241-9760 login: guest)
  7. References: <2b3de6cf@p15.f202.n281.z2.fidonet>
  8. Date: Sun, 3 Jan 1993 03:53:43 GMT
  9. Lines: 35
  10.  
  11. In article <2b3de6cf@p15.f202.n281.z2.fidonet> p15.f202.n281.z2.fidonet!Vincent_Partington@nextjk.wlink.nl writes:
  12. >In a message of <Fri 25 Dec 92 20:52>, Conan Ford (2:281/202.0) writes:
  13. >
  14. > CF>  one and set up some pointers to each "page".  This is because of
  15. > CF>  the problems GEMDOS has when you use MALLOC for more than 20
  16. > CF>  seperate buffers (e.g. system crash :-)  ).
  17. > CF>  (Though you probably know :-)   )
  18. >
  19. >Let's just hope this BUG has been fixed in MiNT. There it would REALLY be
  20. >annoying. It's annoying now, you have to allocate memory and manage it
  21. >yourself but of course TOS should do that for you.
  22.  
  23. The 20 Malloc per program limit was removed a long time ago (certainly
  24. it was gone in TOS 1.4). And, of course, MiNT has no such limit.
  25.  
  26. Managing memory "yourself" (i.e. by asking the operating system for
  27. large blocks of memory, and having your own malloc() function split
  28. those large blocks up for your program) is still a good idea, for 2
  29. reasons:
  30.  
  31. (1) it's faster (entering the OS is always going to add overhead), and
  32. (2) it may save memory: on a virtual memory or memory protected system,
  33.     the OS must manage memory in pages; so even if you ask for 1 byte,
  34.     an entire page (4K or 8K) must be used by the OS for your block
  35.     of memory.
  36.  
  37. Most libraries' malloc() functions will handle everything automatically,
  38. allocating memory in large chunks (4K or 8K or even 32K) from the OS
  39. and then splitting those chunks up as necessary. See for example the
  40. MiNT or GNU C library malloc()/sbrk() code. All the programmer has to
  41. remember is to use the standard C malloc()/free() functions instead
  42. of the Atari specific Malloc()/Mfree() functions.
  43.  
  44. Eric Smith    ersmith@netcom.com    ersmith@atari.uucp
  45.  
  46.