I have wrote one sample com server which implements com connection point. I am calling one method in this COM object which in turn calling some other method in my client code using connection point mechanism.
But all the above listed operation is synchronous communication. I would like to make COM server pure async so that if my COM server get some event it should fire the data back to its client.
please suggest how it is possible using COM connection point.
Note :- My COM server is running as a exe out of proc.
Thanks in advance!!!
Regards
Ashish
Threading is never a minor detail in COM, just as it isn't in any runtime environment. You must observe the apartment state that the COM client program selected. And if it is STA, by far the most common selection, then it is your duty to fire the event on the thread that the client code selected. Ignoring that requirement just produces impossible to diagnose bugs in the client program.
So if you fire the event from a worker thread in your own code, the only way to get event handlers to run async, then you must marshal the interface pointer. CoMarshalThreadInterfaceInStream() or the easier-to-use IGlobalInterfaceTable gets that job done. Rock-hard requirement. It will run asynchronously when the client program opted-in by using COINIT_MULTITHREADED when it called CoInitializeEx(). The only thing you can do is publish the fact that your code is thread-safe by picking the ThreadingModel registry value, using "Both" or "Free".
Same as you do it without COM:
the client of your server object calls a method;
the method starts a background operation and returns;
The background operation can use a separate thread, an async I/O API, a timer API, etc. When the background operation has completed, it fires an event (calls a method on the client-provided sink interface);
the client handles the event.
Back to COM, all method invocations in COM are synchronous by default. When you fire an event on the client-provided sink interface, the call will block until the client returns. There's one exception to this behavior: IAdviseSink. The methods of this interface are asynchronous, if the callee resides in a different COM apartment from the caller. However, IAdviseSink is probably not what you're looking for.
The standard way to use asynchronous COM requires that the interface have an separate UUID for the asynchronous interface. IConnectionPoint does not have an async UUID, so you can't use ICallFactory to implement asynchronous COM.
Related
How do I send a message to a handle_message callback function of a web-socket callback module to update its InternalState from another web-socket callback module??
If you want Yaws websocket callback processes to know about other such processes, you'll have to create some sort of registry yourself. Yaws websocket processes are unregistered because Yaws has no need to find them; each is associated with a socket, and activity on their respective sockets is how their messages get to them.
One way to implement such a registry would be to have the websocket callback module init function call erlang:register/2, but that approach suffers from the problem of needing a new atom name for each callback process, and if your server runs long enough you'll run out of atoms and crash the Erlang VM.
A better approach is to create a gen_server registry process that manages an ets table, and then have the websocket callback module init function register itself with that process, which would then store the details into the ets table. A callback process could find another one either by accessing the ets table directly (assuming it allows public reads), or by calling a query function on the registry process, though note that in the latter case if such calls are frequent and there are lots of websocket processes, the registry could be a bottleneck.
The second approach allows you to use keys other than atoms, such as strings, integers, or binaries, and so it doesn't suffer from the problem of running out of atoms. Another benefit is that the registry process can monitor each registered websocket callback process and remove them from the registry when they die.
If you're not using Yaws in embedded mode, you could use the yapps feature of Yaws to start an application of your own, running co-located with Yaws, to start a supervisor that then starts and manages the registry process. In this case, there's no need to register the yapp with each virtual server as the docs suggest, since the yapp itself wouldn't be handling Yaws requests.
I have a similar approach. If you have more than one Yaws server to handle websocket, you can store the websocket Pid to mnesia, and use Pid ! Message to send message to specific websocket Pid, finally the websocket callback module handle_info/2 will be called.
After using several different messaging and RPC systems I have come to the conclusion that you eventually always need traditional RPC, and push events of some kind. Otherwise you inevitably end up with some polling hack.
For example, HTTP originally only supported RPC-style methods (GET and POST return a response immediately). People realised that push events were needed so hacked it using long polling. Eventually this was fixed with Server-Sent Events.
CoAP (a lightweight UDP-based version of HTTP) also supports push events by adding a 'monitor' option to GET requests. It's a pretty elegant solution.
But neither of those are Thrift-style RPC, by which I mean you write an interface definition file, and there is some tool that compiles that interface into native code for your language of choice. Thereafter you can just call remote procedures almost as if they are local ones.
So my question is, are there any Thrift-style RPC systems that let you subscribe to push events and call a callback (or similar) when an event arrives?
Yes:
gRPC supports "streaming", which means a single logical RPC call can actually involve multiple messages in each direction.
Cap'n Proto supports object capabilities, which allows either side of the connection to send an object reference to the other side, to which calls can be made. For example, the client could call a method on the server and, as one of the method parameters, provide a callback object. The callback object implements some pre-defined RPC interface. When the server calls the callback object, it is making a call back to the client. In fact, Cap'n Proto connections are fully symmetric: there is no distinction at the protocol level between client and server.
(Disclosure: I am the author of Cap'n Proto, and was also the author of Protocol Buffers v2, though I am not affiliated with gRPC.)
I would like to communicate between two processes running on the same machine.
I don not have luxury to use any sort of general IPC(e.g. shared memory, pipe, sockets etc.)
I can able to use window messages to communicate between both the process.
please advice will it be faster to use COM connection point rather than window messages.
Is COM connection point also based on window message queue.
Any help will be greatly appreciated.
Regards
Ashish
please advice will it be faster to use COM connection point rather
than window messages.
It largely depends on how you use Windows messages to communicate between processes.
For simple cases like calling a COM method without arguments, a synchronous inter-process call will not be faster than using SendMessage directly, because of the reason explained below.
Is COM connection point also based on window message queue.
It is not based on window message queue. COM connection point is just a convention for implementing outgoing COM interfaces. However, the COM inter-process marshaller does indeed use hidden windows and private messages to marshal calls, when it comes to making an out-of-proc call on a connection point interface.
This is not specific to connection points and applies to any COM proxy interface you may have cached. Normally, you need to have a functional message loop inside both client and server processes for this to work properly.
I would like to write one com SERVER in such a way so that each new client request to this com server should be served by separate thread.
So far I have created one sample MTA out of proc COM server, but what I observe when I make a com function call is..
this pointer is separate in a com function call(i.e. each cocreateinstance is creating separate com object)
if I print GetCurrentThreadID() in the COM function, then it gives same value for each of my client.
it means there is only one com thread serving all of my client requests.
please advice how we can separate thread for every client. I can afford multiple running exe of the same com server.
Any help will be greatly appreciated!!!
The synchronous calls in C# can be converted to a asynchronous calls by creating a new delegate, and then the BeginInvoke can be called on that delegate. The same operation can be done by without creating a delegate, but call the ThreadPool::QueueWorkerItem method. As I understand both methods do the same job. The delegate::BeginInvoke is little more coding but easy to understand. Do these operations both use thread pool to do the asynchronous operation internally?
After testing a sample app, I have found out that delegate::BeginInvoke invokes the call in a different thread. Internally it might be using ThreadPool to create a background worker thread to complete the job because the callback can't modify the controls which is created by the UI thread.