It is difficult to access the address space of anything but the currently running process in Linux. In fact, it is not generally possible: the process's memory may be swapped to disk. This means buffering all messages in kernel space before causing a context switch to the process for which the message is destined. Unfortunately this requires all data to be copied from sender to kernel to receiver, whereas under QNX, message passing results in a single copy directly from the sender's address space to the receiver's.

There's a problem with pre-2.2 Linux kernels involving the use of fork() when the parent exits, and the child never makes an SRR Module library call. This problem does not exist in the 2.2.0 and later kernels.

In Unix, when a process forks, its file descriptors are duplicated in the child. In Linux this dup() is done without the co-operation of the driver to which the fd points, which is usually a good thing. However, the only way a given module can detect the death of a process is when that process closes the fd it uses to communicate with the module. That module needs to know about process death to release any processes that may be blocked on it. A call to close() on process exit/ death is guaranteed when a single process has a copy of the fd.

However, when a process forks, both the parent and the child have the fd open, and it will not close until both processes close it. This can happen explicitly via the close() function, or on exit. This can lead to scenarios where the parent exits, but the child still holds the fd open, so the kernel module never realizes a process has exited. We try to compensate for this by detecting when a process uses any of the APIs through a fd that it did not originally open, then forcing that process to open its own fd. Unfortunately, if the child never makes any API calls, we never know the parent died.

In Linux 2.2 closing a fd is indicated by flush being delivered to the module. If it is the last close, the flush is followed by a release. This is sufficient information for the module to operate correctly under all conditions. See tfork.c in the distribution for an example demonstrating the bug. The example also demonstrates that the bug does not exist when using the module under a 2.2 or later kernel.

The error numbers for certain irrational errors, such as sending a message to oneself or attaching a proxy to a proxy are not covered in the QNX documentation. The system will throw an error, but the errno may not be correct. Also, contrary to what the QNX documentation says, it is possible to call qnx_proxy_detach() on any proxy, assuming you have sufficient privileges, not just on proxies attached to you.