Hi Abhishek, you are saying that there could be issues in running the 4 functions in multithreading scenario. That?s a good point, but perhaps the issues can be minimized by synchronizing the running of the 4 threads (at least for now), until issues are resolved. That way, we would still get the desire effects of not waking up unnecessarily.
It?s not clear what you meant by csdk users not handling multi-thread scenario, can you describe more? I assume the users of the csdk apis are the (sample) apps, security, and C++ (OCPlatform, OCResource). And your point is that these apps could now get simultaneous calls from the 4 functions. If so then yes, it will need to be resolved as well after the stack side is fix. Or another possibility is to let the apps opt in. Thanks for the info Abhishek. From: Abhishek Sharma [mailto:[email protected]] Sent: Thursday, March 9, 2017 9:31 PM To: Soemin Tjong <stjong at exchange.microsoft.com> Cc: iotivity-dev at lists.iotivity.org; Way Vadhanasin <Wayakorn.Vadhanasin at microsoft.com> Subject: RE: [dev] Make OCProcess( ) needed only on single threaded platform Agree it would be great if app developers need not worry about popping that extra thread to keep calling OCProcess(). But I think removing this function now would be tricky and not limited to just removing single api. All users of csdk api's will require handling of multi-thread scenario, which they most probably might not be doing now. Also csdk (oc* files) will have to be reviewed to support multi-threading, for ex: global variables will have to be removed or put under lock. CA layer (ca* files) was designed to be multi-threaded from begining so you will face no issues there. Regards Abhishek Sharma --------- Original Message --------- Sender : Soemin Tjong <stjong at exchange.microsoft.com<mailto:stjong at exchange.microsoft.com>> Date : 2017-03-10 08:09 (GMT+5:30) Title : [dev] Make OCProcess( ) needed only on single threaded platform Hi all, we are investigating https://jira.iotivity.org/browse/IOT-1828<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjira.iotivity.org%2Fbrowse%2FIOT-1828&data=02%7C01%7Cstjong%40exchange.microsoft.com%7C4b7f0cb9bddb4964bd8d08d46776a638%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636247206678818084&sdata=y%2BeydPdFTFUoy9BsBe5I%2BrIv%2F1nNMu4NkOkAMrJUEg8%3D&reserved=0> and can use some input. Currently code that uses ocstack needs to periodically call OCProcess( ) (most call it every 10 ms). The OCProcess( ) performs 4 functions: (1) process received packets, (2) handle presence, (3) handle gateway routing, and (4) handle TCP keepalive. Waking up often is not great for applications running on battery operated devices. We think calling OCProcess() should only be needed on single threaded platforms, like Arduino (i.e. when SINGLE_THREAD is defined). Looking at camessagehandler.c, it seems like the IoTivity code was at some point able to handle its own send & receive. Then SINGLE_HANDLE flag was set permanently and function (1) is now handled by periodic OCProcess( ) instead. Does anyone know the history of SINGLE_HANDLE? We want to propose making OCProcess( ) needed only on single threaded platform. To do that we?ll re-enable the receive thread, remove all references to SINGLE_HANDLE, and subsequently add new thread(s) to perform function 2 to 4. Can anyone think why this won?t work? Thanks! _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> https://lists.iotivity.org/mailman/listinfo/iotivity-dev [cid:image001.png at 01D2991F.E2D98DB0] [http://ext.samsung.net/mail/ext/v1/external/status/update?userid=ce.abhishek&do=bWFpbElEPTIwMTcwMzEwMDUzMTAxZXBjbXM1cDg4MTIwNGExMjExMTlhYWJkMTQzMzQ2Yzk4NWMzODk0NCZyZWNpcGllbnRBZGRyZXNzPXN0am9uZ0BleGNoYW5nZS5taWNyb3NvZnQuY29t] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170310/f9361420/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 33527 bytes Desc: image001.png URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170310/f9361420/attachment.png>
