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!!!
Related
I try to find some fast algorithm of interprocess communication.
One of I need is an ability to send one command to multiple application instances at the same time. I had tried to find out for a day if I am able to start many instances of the same app (local-rpc-server-app) and call RPC from one client. I use ncalrpc protocol for this purpose.
I just want to start several instances of server and one instance if client, and then call the same RPC func one time on a client to evaluate this RPC func on every running server.
Yes, you can either use multiple client threads (each making a separate server call) or modify the .acf and mark the call with the [async] attribute. If you go the latter route you can then make multiple calls on a single client thread. Note that asynchronous RPC is a fair bit more complicated than synchronous RPC due to needing to deal with call completions.
Making calls to multiple server instances (even local instances) is also made more complicated by the fact that you will have to somehow discover those endpoints, and the RPC namespace functions (RpcNs*) are no longer available as of Windows Vista.
I am working on an application where i have separated out two different XPC services from the main application. I want a XPC service to communicate with other XPC service which will do some processing and will return the data back to first service and that first service will do its own processing and then will give data back to the main application. I even tried this but communicating between the services give error that "could not communicate with helper application".
My question is that either this is possible or not? If yes that what is required?
Any help would be appreciated.
Yes, this is possible, but not at all obvious. I asked questions about this exact thing on and off for a year before an obscure hint from an Apple engineer led me to stumble across the answer.
The trick is that you need to transfer the NSXPCListenerEndpoint of one process to another process. That second process can then use that endpoint object to create a direct connection with the first process. The catch is that, while NSXPCListenerEndpoint is NSCoding compliant, it can only be encoded through an existing XPC connection, which makes this problem sound like a catch-22 (you can't transfer the endpoint until you've created a connection, and you can't create a connection until you have the endpoint).
The solution ("trick") is you need an intermediating process (let's call it "cornerstone") that already has an XPC connections that can exchange endpoints between the other two processes.
In my application I ended up creating a daemon process which acts as my cornerstone, but I think you could do it directly in your application. Here's what you need to do:
Create an application with two XPC services, "A" and "B"
In "A" get the listener object for the process: either get the service listener created automatically (listener = NSXPCListener.serviceListener) or create a dedicated, anonymous, listener for the second process (using listener = NSXPCListener.anonymousListener).
Get the endpoint of the listener (listener.endpoint)
The application should ask "A" for its endpoint.
The application can then launch "B" and, using XPC again, pass the endpoint it got from "A" to "B".
"B" can now use the endpoint object it obtained from "A" (via the application) to create a direct connection to "A" using [[NSXPCConnection alloc] initWithListenerEndpoint:aEndpoint]].
So I have found that two processes are inevitably going to be unable to communicate to the same XPCService. That is because if you try to launch an XPCService, it will be a unique process to the launcher. And as far as I can tell, you can only communicate with an XPCService that your process launched.
So I believe your second XPCService will be unable to "launch" the first XPCService, and therefore will be unable to communicate with it.
The best you can probably do is have your second XPCService communicate back to your main application process, which then communicates to the first XPCService.
You could do something like:
[[self.firstXPCConnection remoteObjectProxy] getSomeString:^(NSString *myString) {
[[self.secondXPCConnection remoteObjectProxy] passSomeString:myString];
}];
Though disclaimer, I haven't tried this. But the best I can help you with the knowledge I have
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.
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 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.