82 lines
3.9 KiB
Plaintext
82 lines
3.9 KiB
Plaintext
[section:concepts Concepts]
|
|
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.
|
|
|
|
[section:pipes Pipes]
|
|
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 the same thread reads and write to a pipe, it will only talk to itself.
|
|
|
|
[section:anonymous Anonymous Pipes]
|
|
|
|
The usual type of pipes, are the anonymous ones. Since the 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:
|
|
|
|
* [@http://pubs.opengroup.org/onlinepubs/7908799/xsh/pipe.html posix]
|
|
* [@https://msdn.microsoft.com/de-de/library/windows/desktop/aa365152.aspx windows]
|
|
|
|
[endsect]
|
|
|
|
[section:named Named 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 [@(http://pubs.opengroup.org/onlinepubs/009695399/functions/mkfifo.html fifos],
|
|
which means, that the named pipe behaves like a file.
|
|
|
|
Windows does provide a facility called [@https://msdn.microsoft.com/en-us/library/windows/desktop/aa365150(v=vs.85).aspx named pipes],
|
|
which also have file-like names, but are in a different scope than the actual file system.
|
|
|
|
[note The main reason named pipes are part of this library, is because they need to be internally used for asynchrounous communication on windows.]
|
|
|
|
[endsect]
|
|
|
|
[endsect]
|
|
|
|
|
|
[section:process Processes]
|
|
|
|
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[footnote it is unique as long as the process is active], called the process identification digit, `pid`.
|
|
|
|
[section:exit_code Exit code]
|
|
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 not 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.
|
|
[endsect]
|
|
|
|
[section:termination Termination]
|
|
Processes can also be forced to exit. There are two ways to do this, signal the process to 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.
|
|
|
|
[endsect]
|
|
|
|
[endsect]
|
|
|
|
[section:env Environment]
|
|
|
|
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.
|
|
|
|
[endsect]
|
|
|
|
[endsect] |