Kernel prepatch 4.0-rc4

There were a few technical issues. Although I experienced them with DCOM, I think they are essential to any RPC mechanism with synchronous calls. If they are solved in D-Bus somehow, I will be glad to hear how. Here is a list with no particular order. (Sorry for my bad english in advance.)

1. The most important aspect of every RPC is how incoming calls are handled. I know two models for handling incoming calls: message loop (aka single-threaded apartment in COM) and thread pool (aka multi-threaded apartment in COM).

In first case all incoming calls are serialized with message loop and are handled one by one. This approach has an advantage that one doesn't have to worry about multithreading and it works very well for simple programs. Problems arise for compilated cases. Consider we have two processes A and B. A does a call foo() to B. Inside handling this call B calls bar() to A. And to handle bar() A calls baz() to B. To handle bar() and baz() both A and B should pump a nested message loop inside any outgoing calls. The problem with DCOM is that this nested message loop handles not only incoming calls from processes we are called to, but from _any_ process. Effectively it means that inside _any_ outgoing call _any_ incoming call can be handled. And the program should be prepared for that. It means that after doing outgoing call program state could be changed arbitrary. Needless to say this leads to crazy reentrancy bugs. Also it is difficult to track all places where outgoing calls are made. For example in my case logger was doing a outgoing calls (because one of appenders sends messages to other process), it means that inside LOG macro _any_ incoming function can be handled. As LOG macro was quite popular it means that _any_ function can be called from _any_ other.

* To make things worse not only incoming calls can be handled inside any outgoing call, but any window messages. It means that for example WM_TIMER (equivalent of timerfd) can be handled inside outgoing calls.
* One could argue that the problem is running a nested message loop inside outgoing call. But this is necessary. Consider we have two processes A and B. And then at some point of time A decided to call B, and B decided to call A almost simultaneously. If there is no nested message loop these two processes will deadlock.
* One could argue that the problem is that nested message loop is handling all incoming, while it should only handle incoming calls from the process outgoing call is made to. This is not the case. Consider we have three processes A, B and C. A calls B, B calls C, C calls A.

In case of thread pool things are worse. I tried to write a simple server in multi-threaded apartment and it was a pain. When A calls B and B calls A back, the original thread of A is not the same thread that handles a incoming call from B. It means that recursive mutex become non-recursive one. And there is lots of mutexes and locks in multi-threaded apartment server. Things are getting worse when there is three processes that calls each other.

Theoretically these two approaches could be merged into a better one. Probably some unique thread-id can be propagated through the calls. And if incoming call has the same thread-id as one of our outgoing call it is handled inside this outgoing call as in nested message loop, otherwise a new thread from thread pool is used. This will create an illusion that two processes share the same set of threads and it works well with mutexes. But malicious process could pass a fake thread-id and we will end up with all problems we have with two described approaches. So I don't think this is suitable solution for general purpose RPC mechanism.

2. The second problem is timeouts. When you are doing some outgoing call and there is some problem with a network, the call can timeout. The problem is that timeout value is huge. If I remember correctly in my case the timeout was 2 minute. Here is a quote (http://blog.matrikonopc.com/index.php/ask-the-experts-opc...):
> "Distributed Component Object Model (DCOM) calls may take a long time to time out if the network is down, or if the server is unavailable. The actual DCOM timeout depends on a number of factors, including which network protocol DCOM is using and whether the server or network went down before or during the call. In some cases the timeout may be up to 6 minutes. DCOM makes use of RPC, and although RPC does allow some amount of control over call timeout, the programmer cannot normally take advantage of it because DCOM does not give access to the underlying RPC binding handle."

This is absolutely insane. It means that it is not possible to use any DCOM calls in UI thread. In our case the typical number of DCOM client were 60. If we wait for each for 2 minutes it means our program will hang for 2 hour! Also I want to note that malicious process could hold a thread in your process indefinetely using minimal amount of resources (responding to pings and never sending reponse). In our case we were calling some 3rd party DCOM process that sometimes freezed our process.

3. The third problem was performance. At some point we've got into the problem that under some workload the throughput of logger was bottleneck. Our logger had a function, say, LogMessage(IMessage*) and ILogMessage was

struct ILogMessage
{
virtual HRESULT GetText(BSTR*);
virtual HRESULT GetLevel(LogLevel*);
virtual HRESULT GetTime(TimeStamp*);
...
};

Consider process A calls LogMessage() to process B. Then process B call GetText() to process A. Then process B call GetLevel() to process A. Then process B call GetTime() to process A. Then process B returns control to process A. This interface is used both in-process and between processes. In-process it is reasonable and worked well. Between processes it is insanely ineffective as it does 8 pings between A and B instead of one. The correct way to pass log messages between processes is to collect them and pass them in bulks. But this is not how we pass data inside single process. The roundtrip time between processes is very expensive, but it is extremely cheap inside single process. I think the main problem with synchronous RPC is that it makes an illusion that we simple calls functions, while in reality we are not.

4. Custom marshalling. As time passed more and more compilated structures needed to be passed through DCOM. std::vector, boost::optional, std::pair or just some custom C++ structures. The problem with IDL and DCOM was that is it knows nothing about C++ and templates and standard library. So we had to write a lot of custom boilerplate code to convert our data structures to something that COM understand. Finally we ended up with something like DispatchMessage(void const*, size_t) and do all serialization manually.

5 (CORBA). I did some small server using CORBA. And CORBA has another problem. When client is killed it keeps reference incremented to your objects. It means that malicious client could easily leak your memory (http://www.davidchappell.com/writing/article_Refer_Counti...).

One could argue that problems 1-3 arise only if one uses synchronous calls and that async (in COM, https://msdn.microsoft.com/en-us/magazine/bb984898.aspx)/one way (in CORBA) calls don't have such problem. I think that if one uses only async calls he doesn't need COM at all because god socket and serialization libraries could serve it needs. If one uses synchronous calls he have problems 1-3. Also I argue that using sockets are much simpler than using async calls in DCOM! It worth noting that good serialization library can solve the problem 4.