Kernel prepatch 4.0-rc4

Posted Mar 18, 2015 14:31 UTC (Wed) by JGR (subscriber, #93631)
In reply to: Kernel prepatch 4.0-rc4 by sorokin
Parent article: Kernel prepatch 4.0-rc4

> 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.

One could equally implement synchronous calls using standard socket and serialisation libraries, which would lead to problems 1-3 in much the same way. As I read it, your post is more about synchronous vs asynchronous RPC/messaging, than DCOM vs a custom RPC using sockets.

That said, problems 1-2 can be avoided whilst still using synchronous RPC if the thread making the outbound request does not have it's own event loop which is run during the request. One way to implement that would be to have the event loop dispatch (a subset of) events to a thread pool, though that is not fantastically efficient.

For something like a logger, a fire-and-forget message should be adequate, as there's no point blocking yourself waiting for an acknowledgement which doesn't really tell you anything.

> This is absolutely insane. It means that it is not possible to use any DCOM calls in UI thread.
How is this insane? Any kind of synchronous non-local network IO in a UI thread is a non-starter. Even synchronous local network or disk IO is potentially problematic.

Kernel prepatch 4.0-rc4

Posted Mar 18, 2015 18:00 UTC (Wed) by sorokin (guest, #88478) [Link] (1 responses)

> One could equally implement synchronous calls using standard socket and serialisation libraries, which would lead to problems 1-3 in much the same way. As I read it, your post is more about synchronous vs asynchronous RPC/messaging, than DCOM vs a custom RPC using sockets.

Absolutely.

> That said, problems 1-2 can be avoided whilst still using synchronous RPC if the thread making the outbound request does not have it's own event loop which is run during the request. One way to implement that would be to have the event loop dispatch (a subset of) events to a thread pool, though that is not fantastically efficient.

This is what we have implemented. DCOM supports asynchronous calls, but I don't remember why they we not used.

> For something like a logger, a fire-and-forget message should be adequate, as there's no point blocking yourself waiting for an acknowledgement which doesn't really tell you anything.

Agree. This is why I think CORBA-like oneway calls are sound.

> Any kind of synchronous non-local network IO in a UI thread is a non-starter. Even synchronous local network or disk IO is potentially problematic.

I was not an original author of the program. When I started working on it, it was already ridden with synchronous calls to other services. And this was sealed deep into program logic. Also sometimes it was difficult to track what call can be synchronous because the same interface could be implemented by local object or by remote one.

Kernel prepatch 4.0-rc4

Posted Mar 18, 2015 18:11 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

> This is what we have implemented. DCOM supports asynchronous calls, but I don't remember why they we not used.
AFAIR, it was supported first in WinXP and were never really popular.