Running multiple mg_mgrs in separate threads on version 7.10 #2266
-
|
Hello, The latest documentation still displays this statement: An entry in the discussion forum, (#1527) seems to imply that the above statement is no longer true, and multiple mg_mgrs can now be implemented in different threads. Our intended application uses multiple WebSocket servers that have somewhat strict timing requirements for some sent messages to their respective clients. This application also uses a REST API client to connect to a device that may disconnect at any time. Therefore, our application will have to periodically retry connecting to the device if that occurs. The problem we are having, is that the single thread that is calling mg_poll() is getting blocked by the REST client attempt to connect to the offline device until the socket connect timeout period has expired, which in turn violates our WebSocket server timing. I believe having separate threads (and mg_mgrs) to deal with the WebSocket servers, and REST client, should resolve the thread blocking issue. Please advise on the current status (v7.10) of the core being thread safe. Or if not, perhaps the community has some suggestions on how to handle the above application requirements. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
All mg_* functions refer to an event manager If you run several managers, either in one or in different threads, they won't share anything among themselves, just make sure that all calls interacting with a manager are done from the same context as the manager. What you cannot do is to run a manager in thread A and call a function that uses it from thread B. If you need to do something like this, like worker threads to handle requests, there is an example on how to do it properly: multi-threading. Besides that, I don't understand your issue, our clients do not block, if they do you are not doing something right. In that case, please open an issue |
Beta Was this translation helpful? Give feedback.
All mg_* functions refer to an event manager
That statement is correct, it says that all calls to api functions and a manager must be on the same context (be it threads or interrupts)
If you run several managers, either in one or in different threads, they won't share anything among themselves, just make sure that all calls interacting with a manager are done from the same context as the manager.
What you cannot do is to run a manager in thread A and call a function that uses it from thread B. If you need to do something like this, like worker threads to handle requests, there is an example on how to do it properly: multi-threading.
Besides that, I don't understand your issue, our clients…