René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Unprotected callbacks from CAN RX thread","articleBody":"In my work of porting canopen to asyncio, I stubled across that canopen contains a lot of unprotected thread crossings. By and large all callbacks coming from can through `Network.notify()` run in another thread. This means that all subscribed callbacks must protect any class members access, otherwise interesting results may arise. Many callback handlers have synchronization mechanisms, but there a still quite a few that does not.\r\n\r\n```\r\nemcy.py:EcmyConsumer.on_emcy()  Callbacks are not protected\r\nnetwork.py:NodeScanner.on_message_received()  self.nodes is not protected\r\nnmt.py:NmtBase.on_command()  self._state is update and not protected\r\nnmt.py:NmtSlave.on_command()  self.update_heartbeat() is called which alters state\r\nprofiles/p402.py:BaseNode402.on_TPDOs_update_callback()  self.tpdo_values[] updated from thread\r\nsdo/server.py:SdoServer:on_request()  Modifies lots of variables\r\n```\r\n\r\nI haven't investigated how many of these have an implicit safe design. This issue is mostly for information, but in general race conditions due to missing synchronization protection is sporadic and hard to debug.","author":{"url":"https://github.com/sveinse","@type":"Person","name":"sveinse"},"datePublished":"2021-11-13T23:41:31.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":3},"url":"https://github.com/284/canopen/issues/284"}