GEOS SDK TechDocs
|
| 
2 The Global Handle Table
Many handles are not kept in the global handle table. For example, a block of memory may be declared as a "local-memory (LMem) heap." An LMem heap can contain many different chunks of data; the LMem manager moves these chunks around to make room for new ones. Each chunk is referenced via a chunk handle . (For more details about LMem heaps, see the Local Memory chapter.)
Local handle tables are useful when a handle needs to persist across GEOS shutdowns. For example, data in VM files is accessed by its block handle. These handles therefore need to remain the same every time the file is opened.
Some local handle tables are intended to be directly accessible to geodes. For example, LMem Chunk handles are simply offsets into the block containing the LMem heap; the address specified by that offset contains another offset value, which is the offset to the chunk. This scheme is part of the LMem API. Geodes which are written in assembly generally look up chunk handles themselves, instead of calling a system routine to translate the chunk handle into an address. (Goc code generally dereferences a chunk handle with a call to
LMemDeref()
.) Some other local handle tables are intended to be opaque to geodes. For example, applications treat VM block handles as opaque 16-bit tokens; to dereference a VM handle, a geode must pass it to an appropriate system routine (such as
VMLock()
).
Local handles are used by many different libraries; among them are the LMem, VM, Database, and Cell libraries. The details differ with each library; for more information, see the appropriate chapter. An object-descriptor is a combination of two handles: the handle of the global memory block containing the object, and the chunk handle of the object itself. For more information, see the GEOS Programming chapter.
GEOS SDK TechDocs
|
| 2 The Global Handle Table