libmkkernel 9.0
Loading...
Searching...
No Matches
Functions | Variables
MkKernel_Setup_C_API

Setup und Cleanup the libmkkernelMore...

+ Collaboration diagram for MkKernel_Setup_C_API:

Functions

MK_EXTERN void MkSetup (void)
 setup libmkkernel internal memory …
 
MK_EXTERN void MkCleanup (void)
 cleanup libmkkernel internal memory …
 
MK_EXTERN bool MkHasThread (void)
 
MK_EXTERN bool MkHasFork (void)
 

Variables

MK_EXTERN_DATA bool MkCleanupActive
 signal that code was triggert by MkCleanup
 

Detailed Description

Setup und Cleanup the libmkkernel

Initializing a libmkkernel library depends on the target language and the specific nature of the Programming-Language-Micro-Kernel.

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

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

shared library detail

A new libmkkernel 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 libmkkernel library startup functions

MK_EXTERN void MK_DECL MkSetup (void) __attribute__ ((constructor(200)));
MK_EXTERN void MK_DECL MkCleanup (void) __attribute__ ((destructor(200)));
#define MK_DECL
Definition kernel_mk.h:2159
#define MK_EXTERN
static library
Definition kernel_mk.h:2557
MK_EXTERN void MkCleanup(void)
cleanup libmkkernel internal memory …
MK_EXTERN void MkSetup(void)
setup libmkkernel internal memory …

In the Programming-Language-Micro-Kernel, a type is defined for each thread, which means that the new libmkkernel library must be known when the thread starts. This is not a problem as long as the external libmkkernel library is linked to the application. However, if dlopen is used to load the libmkkernel library, the current restriction is that the new data type from the libmkkernel 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.

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

Example: Start of the ConfigServer application from the example/csharp directory

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

Function Documentation

◆ MkCleanup()

MK_EXTERN void MkCleanup ( void  )

cleanup libmkkernel internal memory …

MkCleanup will only be recognized once and will be ignored if not called in the same thread as MkSetup. After a call to MkSetup the call to MkCleanup is possible again.

‍The public MkCleanup is just a placeholder, the internal MkCleanup is always called even if the public MkCleanup is not called.

Attention
during cleanup objects will be deleted too -> the language interpreter have to be active

◆ MkHasFork()

MK_EXTERN bool MkHasFork ( void  )

◆ MkHasThread()

MK_EXTERN bool MkHasThread ( void  )

◆ MkSetup()

MK_EXTERN void MkSetup ( void  )

setup libmkkernel internal memory …

MkSetup will only be recognized once, additional call's will be ignored until a MkCleanup is called.

‍A call to the public MkSetup is required if dlopen and thread is used.

Variable Documentation

◆ MkCleanupActive

MK_EXTERN_DATA bool MkCleanupActive

signal that code was triggert by MkCleanup

Definition at line 3675 of file kernel_mk.h.