MkKernel_Setup_libmkkernel_CC_API

MkKernel PACKAGE - Setup und Cleanup the ccmkkernel … More...

Collaboration diagram for MkKernel_Setup_libmkkernel_CC_API:

Functions
static void	ccmkkernel::MkKernel::Cleanup ()
	C++: [static] MkKernel::Cleanup() → C-API cleanup ccmkkernel internal memory …
static void	ccmkkernel::MkKernel::Setup ()
	C++: [static] MkKernel::Setup() → C-API setup ccmkkernel internal memory …
static void	ccmkkernel::MkKernel::CcMkCleanup ()
	C++: [static] MkKernel::Cleanup() → C-API cleanup ccmkkernel internal memory …
static void	ccmkkernel::MkKernel::CcMkSetup ()
	C++: [static] MkKernel::Setup() → C-API setup ccmkkernel internal memory …

Detailed Description

MkKernel PACKAGE - Setup und Cleanup the ccmkkernel …

Initializing a ccmkkernel library depends on the Target-Programming-Language (TPL) and the specific nature of the Programming-Language-Micro-Kernel (PLMK).

In general it is required to call a Setup style funtion as FIRST command because of:

• In a static build the shared library constructor/destructor is NOT called
• In a shared build the order of library loading is target-language-specific
• Every executable who uses a meta-code-library (META-LIBRARY) (MkKernel, MqMsgque, LcConfig, ...) which provide a language-specific-type (always assume this) and also support static-build (no constructor is called like C, C++, ...) require a call to the meta-library-setup-function for type-initialization at startup.

If more than one META library is called only the toplevel Setup is required:

• example: The MkKernelSetup is not required if MqMsgqueSetup or LcConfigSetup is already used.

shared library detail

A new ccmkkernel library is initialized with Setup and released again with Cleanup. Both functions are automatically called upon loading and unloading of the shared library.

Example: Definition (C) of the ccmkkernel library startup functions

MK_EXTERN void MK_DECL MkSetup (void) __attribute__ ((constructor(200)));
MK_EXTERN void MK_DECL MkCleanup (void) __attribute__ ((destructor(200)));

In the Programming-Language-Micro-Kernel (PLMK), a type is defined for each thread, which means that the new ccmkkernel library must be known when the thread starts. This is not a problem as long as the external ccmkkernel library is linked to the application. However, if dlopen is used to load the ccmkkernel library, the current restriction is that the new data type from the ccmkkernel library has not been defined in all existing threads.

The point in time when a library is loaded depends heavily on the programming language used.

• A linked language such as C or C++ usually has all libraries initialised at startup.
• A compiled language such as Java and C# only load a library when a function of the library is used and not when the library is declared.
• A scripting language such as Tcl normally loads the library as soon as the declaration (package require myLib) is made, which happens fairly close to the start of the program but is not guaranteed.

‍To avoid all the problems call the Setup directly at the start of the main program.

Example: Start of the LcConfigServer application from the example/cs directory

• The problem with the LcConfigServer application is that the libmkkernel and libmqmsgque libraries are loaded very early, at startup, and the liblcconfig very late, only on request.

static void Main(string[] argv) {
 
  LcConfig.Setup();
 
  var srv = MqFactoryCT<LcConfigServer>.Add().New();
 
  try {
    srv.LinkCreate(argv);
    srv.ProcessEvent(MqWaitOnEventE.FOREVER);
  } catch (Exception e) {
    srv.ErrorCatch(e);
  }
  srv.Exit();
}

Initializing a ccmkkernel library depends on the Target-Programming-Language (TPL) and the specific nature of the Programming-Language-Micro-Kernel (PLMK).

In general it is required to call a Setup style funtion as FIRST command because of:

• In a static build the shared library constructor/destructor is NOT called
• In a shared build the order of library loading is target-language-specific
• Every executable who uses a meta-code-library (META-LIBRARY) (MkKernel, MqMsgque, LcConfig, ...) which provide a language-specific-type (always assume this) and also support static-build (no constructor is called like C, C++, ...) require a call to the meta-library-setup-function for type-initialization at startup.

If more than one META library is called only the toplevel Setup is required:

• example: The MkKernelSetup is not required if MqMsgqueSetup or LcConfigSetup is already used.

shared library detail

A new ccmkkernel library is initialized with Setup and released again with Cleanup. Both functions are automatically called upon loading and unloading of the shared library.

Example: Definition (C) of the ccmkkernel library startup functions

MK_EXTERN void MK_DECL MkSetup (void) __attribute__ ((constructor(200)));
MK_EXTERN void MK_DECL MkCleanup (void) __attribute__ ((destructor(200)));

In the Programming-Language-Micro-Kernel (PLMK), a type is defined for each thread, which means that the new ccmkkernel library must be known when the thread starts. This is not a problem as long as the external ccmkkernel library is linked to the application. However, if dlopen is used to load the ccmkkernel library, the current restriction is that the new data type from the ccmkkernel library has not been defined in all existing threads.

The point in time when a library is loaded depends heavily on the programming language used.

• A linked language such as C or C++ usually has all libraries initialised at startup.
• A compiled language such as Java and C# only load a library when a function of the library is used and not when the library is declared.
• A scripting language such as Tcl normally loads the library as soon as the declaration (package require myLib) is made, which happens fairly close to the start of the program but is not guaranteed.

‍To avoid all the problems call the Setup directly at the start of the main program.

Example: Start of the LcConfigServer application from the example/cs directory

• The problem with the LcConfigServer application is that the libmkkernel and libmqmsgque libraries are loaded very early, at startup, and the liblcconfig very late, only on request.

static void Main(string[] argv) {
 
  LcConfig.Setup();
 
  var srv = MqFactoryCT<LcConfigServer>.Add().New();
 
  try {
    srv.LinkCreate(argv);
    srv.ProcessEvent(MqWaitOnEventE.FOREVER);
  } catch (Exception e) {
    srv.ErrorCatch(e);
  }
  srv.Exit();
}

Initializing a ccmkkernel library depends on the Target-Programming-Language (TPL) and the specific nature of the Programming-Language-Micro-Kernel (PLMK).

In general it is required to call a Setup style funtion as FIRST command because of:

• In a static build the shared library constructor/destructor is NOT called
• In a shared build the order of library loading is target-language-specific
• Every executable who uses a meta-code-library (META-LIBRARY) (MkKernel, MqMsgque, LcConfig, ...) which provide a language-specific-type (always assume this) and also support static-build (no constructor is called like C, C++, ...) require a call to the meta-library-setup-function for type-initialization at startup.

If more than one META library is called only the toplevel Setup is required:

• example: The MkKernelSetup is not required if MqMsgqueSetup or LcConfigSetup is already used.

shared library detail

A new ccmkkernel library is initialized with Setup and released again with Cleanup. Both functions are automatically called upon loading and unloading of the shared library.

Example: Definition (C) of the ccmkkernel library startup functions

MK_EXTERN void MK_DECL MkSetup (void) __attribute__ ((constructor(200)));
MK_EXTERN void MK_DECL MkCleanup (void) __attribute__ ((destructor(200)));

In the Programming-Language-Micro-Kernel (PLMK), a type is defined for each thread, which means that the new ccmkkernel library must be known when the thread starts. This is not a problem as long as the external ccmkkernel library is linked to the application. However, if dlopen is used to load the ccmkkernel library, the current restriction is that the new data type from the ccmkkernel library has not been defined in all existing threads.

The point in time when a library is loaded depends heavily on the programming language used.

• A linked language such as C or C++ usually has all libraries initialised at startup.
• A compiled language such as Java and C# only load a library when a function of the library is used and not when the library is declared.
• A scripting language such as Tcl normally loads the library as soon as the declaration (package require myLib) is made, which happens fairly close to the start of the program but is not guaranteed.

‍To avoid all the problems call the Setup directly at the start of the main program.

Example: Start of the LcConfigServer application from the example/cs directory

• The problem with the LcConfigServer application is that the libmkkernel and libmqmsgque libraries are loaded very early, at startup, and the liblcconfig very late, only on request.

static void Main(string[] argv) {
 
  LcConfig.Setup();
 
  var srv = MqFactoryCT<LcConfigServer>.Add().New();
 
  try {
    srv.LinkCreate(argv);
    srv.ProcessEvent(MqWaitOnEventE.FOREVER);
  } catch (Exception e) {
    srv.ErrorCatch(e);
  }
  srv.Exit();
}

Function Documentation

CcMkCleanup()

void ccmkkernel::MkKernel::CcMkCleanup ( )

static

C++: [static] MkKernel::Cleanup() → C-API
cleanup ccmkkernel internal memory …

Definition at line 96 of file LibMkKernel_cc.cc.

                               {
    MkRtSetup_NULL;
    MkRuntimeCallbackDel( MK_RT_CALL &sMkRuntimeCallback );
    MkCleanup();
  }

Here is the caller graph for this function:

CcMkSetup()

void ccmkkernel::MkKernel::CcMkSetup ( )

static

C++: [static] MkKernel::Setup() → C-API
setup ccmkkernel internal memory …

Definition at line 104 of file LibMkKernel_cc.cc.

                             {
    MkSetup();
    AllRtSetup_NULL;
 
    MkRuntimeCallbackAdd( MK_RT_CALL &sMkRuntimeCallback, mk_static_init_callback, "CcMkKernel" );
  }

Here is the caller graph for this function:

Cleanup()

void ccmkkernel::MkKernel::Cleanup ( )

static

C++: [static] MkKernel::Cleanup() → C-API
cleanup ccmkkernel internal memory …

Definition at line 124 of file LibMkKernel_cc.cc.

                           {
    MkRtSetup_NULL;
    MkCleanupTmpl();
  }

Setup()

void ccmkkernel::MkKernel::Setup ( )

static

C++: [static] MkKernel::Setup() → C-API
setup ccmkkernel internal memory …

Definition at line 130 of file LibMkKernel_cc.cc.

                         {
    MkRtSetup_NULL;
    MkSetupTmpl();
  }