In this example, a set is reserved. The underlying implementation is a linked-list. Then, an object is added to the set.

Notice that, the user of the set manager does not care about how the object is stored internally.

Finally, the user ask the set manager to find and return an object with the given identifier o.id. Then, the permissions of this segment are modified.

Since every manager uses the set, the set manager may seem quite complex.

We said before that the set manager manages set objects, these set objects being used to store data. Note that, the set objects are also stored in a set object. Indeed, the set manager uses itself to store the set objects. The special set object which stores the set objects is called the set container.

The figure below illustrates the sets.

The reader should notice on this figure that the set container holds three set objects.

One of this set is used to hold task objects.

Task objects are basically composed of memory and threads. For this reason, each task contains a set of threads.

The figure illustrates this massive use of sets.

4.5 Process

The kaneton microkernel uses a specific nomenclature which is different from other operating systems.

The system is composed of five different entities in relation with execution.

A module represents a passive execution entity in main memory. Indeed, a module does not run and has no execution context. The modules are managed by the module service to reside in main memory the time it is necessary. For example a very used program like /bin/ls certainly becomes an important module due to its frequent use.

Fundamental system's drivers and services are persistent modules because they would be used in the case of a crash to restart the crashed service without any dependency to the hard drive device driver, for example.