|
Home | Libraries | People | FAQ | More |
In this section, some of the underlying concepts of the operating system used in this library, will be explained. In the following chapters we will presume knowledge of that. Though please note, that this is a short summary and not conclusive of everything that can be done.
The goal of this library is to implement a portable wrapper, so that we will explain mostly what windows and posix have in common.
Pipes are a facility for communication between different threads, processes and in some cases machines, the operating system provides.
The typical feature of a pipe is, that it is one channel, to which two handles are given, one for reading (source), one for writing (sink). In that it is different than other facilities (like sockets) and provides another way to manage the connectivity: if one side of the pipe is closed (i.e. the pipe is broken), the other is notified.
Pipes are typically used for interprocess communication. The main reason is, that pipes can be directly assigned to the process stdio, i.e. stderr, stdin and stdout. Additionally, half of the pipe can be inherited to the child process and closed in the father process. This will cause the pipe to be broken when the child process exits.
Though please note, that if the same thread reads and writes to a pipe, it will only talk to itself.
The most common pipes are anonymous. Since they have no name, a handle to them can only be obtained from duplicating either handle.
In this library the following functions are used for the creation of unnamed pipes:
As the name suggests, named pipes have a string identifier. This means that a handle to them can be obtained with the identifier, too.
The implementation on posix uses fifos, which means, that the named pipe behaves like a file.
Windows does provide a facility called named pipes, which also have file-like names, but are in a different scope than the actual file system.
![[Note]](../../../doc/src/images/note.png) |
Note |
|---|---|
The main reason named pipes are part of this library, is because they need to be internally used for asynchronous communication on windows. |
A process is an independently executable entity, which is different from a thread, in that it has its own resources. Those include memory and hardware resources.
Every process is identified by a unique number[27], called the process identification digit, pid.
A process will return an integer value indicating whether it was successful. On posix there are more codes associated with that, but not so on windows. Therefore there is no such encoding currently in the library. However an exit code of zero means the process was successful, while one different than zero indicates an error.
Processes can also be forced to exit. There are two ways to do this, signal the process to do so and wait, and just terminate the process without conditions.
Usually the first approach is to signal an exit request, but windows - unlike posix - does not provide a consistent way to do this. Hence this is not part of the library and only the hard terminate is.
The environment is a map of variables local to every process. The most significant
one for this library is the PATH
variable, which contains a list of paths, that ought to be searched for executables.
A shell will do this automatically, while this library provides a function
for that.