Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Transparent management of application state across module calls independant of environment

IP.com Disclosure Number: IPCOM000126456D
Original Publication Date: 2005-Jul-18
Included in the Prior Art Database: 2005-Jul-18
Document File: 8 page(s) / 94K

Publishing Venue

IBM

Abstract

A method is described for management of application state across program module calls that is independant of the program environment and transparent to calling and target program modules. In operating systems requiring single instances of programs to execute with global state shared by multiple independant flows of control, this method enables multiple, independantly loaded program modules to interact while ensuring the correct global context is established in each case.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 21% of the total text.

Page 1 of 8

Transparent management of application state across module calls independant of environment

A method is described for management of application state across program module calls that is independant of the program environment and transparent to calling and target program modules.

    For the purpose of this article, the program state in a C language program can be treated as having two principal flavors of storage class (ANSI/ISO9899-19990 Section
6.5.1): auto, where it is allocated from the program's stack, and global, where a single instance of global state is associated with an instance of the program in storage. Depending upon the type of program involved (residency, single vs. multipart, etc.), allocating and locating the global class storage can be simple or very difficult.

    For a program executing in a simple application environment this storage model does not pose a particular problem. Typically, the compiler provides an appropriate prolog that obtains and initialises the global storage and associates that with the thread of control.

    If multiple separately loaded modules are involved, solving this prolem is more difficult. Normally, the operating system is required to provide a sophisticated and complex dynamic loading mechanism (such as ELF/ldd in Linux).

    Where such code is required to execute as a part of the actual operating system, and where a single instance of the program and a single instance of the global state is shared by multiple independent flows of control, neither of the above mechanisms work. This article describes a mechanism which allows multiple, independently loaded, executable units to interact while ensuring that the correct global context is established in each case. Note that this method is specifically related to an environment that does not have the sophisticated dynamic loading environment previously described. A loading mechanism is provided which returns a module token through which a separately loaded program (module) can be referenced. This module token works in conjunction with an interface header file supplied by the loaded module, to provide access to the services provided by the loaded module and when passed on to the loaded module, provides a means for the loaded module to locate its global state. A module token remains valid until such time as the module it refers to is unloaded. The type of the returned module token is incomplete (ANSI/ISO9899-1990 section 6.5.2.3) and cannot be used except via the supplied interface header file.

    The existing notion of function-related frames is used to pass state information (including an appropriate module token) to each function as it is invoked. The caller's state is implicitly restored when control is returned. Each function is required to implement two standard local variables. The specifics of these variables is identical in every case, so a simple macro can be employed to perform this task. A similarly simple macro is employed at each functional egress...