Re: pfDataPools ???

New Message Reply Date view Thread view Subject view Author view

Jim Helman (jimh++at++surreal)
Wed, 24 May 95 13:50:17 -0700

A characteristic of both usinit and pfDataPools is that the address at
which the usinit arena is mapped must be the same in both processes.
This means that if the attaching process has already allocated space,
e.g. from the heap, that conflicts with the usinit arena as mapped by
the creating process, usinit will fail in the attaching process.

The solution (which is built into 2.0) is to use usconfig to specify
a suitable ATTACH_ADDR before calling usinit or pfNewDPool.

rgds,

-jim helman

jimh++at++surreal.asd.sgi.com
415/390-1151

   To: fred++at++vsl.ist.ucf.edu (ALFREDO)
   Cc: info-performer++at++sgi.sgi.com
   Subject: Re: datapools
   In-Reply-To: Your message of "Sun, 08 Jan 95 18:35:13 EST."
                <9501082335.AA26147++at++onyx.vsl.ist.ucf.edu>
   Date: Mon, 09 Jan 95 17:54:48 -0800
   From: Jim Helman <jimh++at++surreal>

   The problem is that pfDataPools must reside at the same space in every
   process (see usinit(1)). Performer currently leaves the choice of
   address up to IRIX. This means that pfNewDPool should be called in
   the larger process and pfAttachDPool should be called as early as
   possible in the smaller process. It's OK to make calls like
   pfNotifyLevel and pfAttachDPool before pfInit(). Errno 16 (EBUSY)
   indicates a memory conflict.

   In the next release, Performer will try to choose a good place in
   virtual address space for datapool arenas. In the meantime, you can
   call usconfig with CONF_ATTACHADDR, to specify an allocation address
   out in the boonies of addressland. Just be sure to set it back to ~0
   after the call to pfNewDPool. My choice for an address would be
   something just below the stack, say between 0x7f000000 and 0x7ff00000.

   rgds,

   -jim helman

   jimh++at++surreal.asd.sgi.com
   415/390-1151

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:51:30 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.