EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Multi-Threaded Message Support

Also by EldoS: CallbackRegistry
A component to monitor and control Windows registry access and create virtual registry keys.
Posted: 03/19/2015 17:53:44
by Mike Nowakowski (Basic support level)
Joined: 03/19/2015
Posts: 1

We’ve begun the processes of implementing MsgConnect as the new IPC method in our software. DispatchMessages is called via a timer on the server and all incoming messages are handled via the OnUnhandledMessage event. We may create separate handlers in the future, but for now we lump them all in OnHandledMessage for simplicity.

The Pseudo code for our OnUnhandledMessage handler is:
Retrieve the source so a response can be sent after processing – Messenger.GetMessageSource
Process the message
Send a response if necessary – Messenger.PostMessage

Messages are retrieved as they come in via DispatchMessages, processed and the appropriate response sent back. Some messages may take an extended period of time to process which leads me to my question/problem. How can we use MsgConnect in a multi-threaded / multi-message-at-the-same-time implementation?

We’ve toyed around with the idea of OnUnhandledMessage spawning worker threads for processing each method. It could loop waiting for any to finish and then send the appropriate response back to the sender. Before diving in I wanted to ask here.

How are others handling multi-threading in their message handlers? Is there a recommended way to handle this? Any pitfalls to watch out for? If it helps, we're using MMF transports in our implementation.
Posted: 03/20/2015 00:18:00
by Eugene Mayevski (EldoS Corp.)

Thank you for contacting us.

There exist several options:

1) DispatchMessages method is thread-safe (it has a singleton object inside) so you can call it from multiple handling threads in parallel. Note that the order of message processing in this situation is not guaranteed, which can fit or not fit to your requirements.

2) Potentially you can use ForwardMessage and DirectTransport to forward the message to the worker thread where it's processed and then sent back.

3) You can handle the message quickly and return some response to the client which will be treated as "the message is being processed, please ask for response in a second or two", and pass the handling to some worker thread. The client would send the same (or slightly modified) request a bit later to pick the result. This scheme is quite complicated, but can be used in more complicated environments.

4) You can handle the message quickly and return some response to the client which will be treated as "the message is being processed, please wait for the reply sent as a message later". Pass the message to the worker thread and pass it the "address" of the sender obtained using GetMessageSource method. The worker thread could then send a new message to this address, thus replying to the client with a new message. Obviously the client should be accessible and be able to receive messages itself.

Sincerely yours
Eugene Mayevski



Topic viewed 3450 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!