rod@bohra.cpg.oz (Rod Bruce) (07/11/90)
Under V.2 we can set the kernel parameter SHMBRK to specify the amount of space that can be dynamically allocated before be bump up against any shared memory segments. We had to set a larger SHMBRK value on our machine so that our program would not crash with a malloc failure. Under V.3 however, the SHMBRK parameter does not exist (at least, I can't find it anywhere) and so I was wondering - 1. How does the system decide where to place shared memory segments? 2. Can we run out of malloc space? 3. Is there anything we can do to ensure that (2) does not happen? Thanx in advance for your advice. -- Rod Bruce, CP Software rod@bohra.cpg.oz D
rod@bohra.cpg.oz (Rod Bruce) (07/11/90)
As per previous but with added signature! -- vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv > Rod Bruce | ACSnet: rod@bohra.cpg.oz[.au] < > CP Software, 9/616 St Kilda Road, | UUCP: ..uunet!munnari!bohra.cpg!rod < > Victoria, Australia, 3004 | Phone: +61-3-5205453 Fax: +61-3-5205414 < D
wescott@Columbia.NCR.COM (Mike Wescott) (07/16/90)
In article <396@bohra.cpg.oz> rod@bohra.cpg.oz (Rod Bruce) writes: > Under V.3 however, the SHMBRK parameter does not exist (at least, I can't find > it anywhere) and so I was wondering - > 1. How does the system decide where to place shared memory segments? It picks the next convenient segment boundary. On the 200 and 700 that means the first shmat will go at 0x4000000 and the next at 0x6000000 On a 6xx, it means the first goes at 0x200000. > 2. Can we run out of malloc space? Yes. At least on the 6xx. On the ohters there's 32Mb for your data, bss and heap. On the 600 it's only 1Mb. > 3. Is there anything we can do to ensure that (2) does not happen? There's always the non-portable define the attach address yourself. -Mike PS. This was ascertained by experimentation rather than perusal of the code. -- -Mike Wescott mike.wescott@ncrcae.Columbia.NCR.COM