Gabriel, I've been aware of this for years, and I wrote a JIRA issue when first found it. So I've had time to think about it.
My original concerns were dismissed with the reply that the current approach (no more than one IoTivity inbound message every 10ms) is a feature, since it prevents DOS attacks. Of course, that was BS when it was first said, and facing that kind of response I dropped it. One issue is working with the variety of environments, where multiple threads either have proprietary primitives or don't exist. The no-threads case is especially irksome, but clever co-routining can make that work. Another potential issue is thread resources, where having the incoming events delivered on a different thread than the one that runs the app is a problem. This is unlikely to be a problem with most of the OSes IoTivity runs on. Of course, the biggest issue is having events delivered to the application asynchronously to the application thread, which requires synchronization that is not specified in the IoTivity API, and which no existing application has. I prefer a solution that doesn't have any time-waits or time-loops. That requires careful use of synchronization primitives, which vary from OS to OS. I believe the cleanest solution is for the IoTivity stack to be defined as single threaded, running entirely on the application thread. This would allow a clean solution with less code, but some people mistakenly believe that threads will make IoTivity higher performance. (In fact, with this change, it would be higher performance.) Unfortunately, the more innovative solutions would require significant architectural changes to the IoTivity stack. I have learned that such changes are hard to propagate in the open-source environment. Good luck working on this tough and important problem. I will be glad to discuss it further. John Light Intel OTC OCF development -----Original Message----- From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Schulhof, Gabriel Sent: Wednesday, June 01, 2016 11:43 PM To: Lenahan, Charlie <charlie.lenahan at intel.com> Cc: iotivity-dev <iotivity-dev at lists.iotivity.org> Subject: Re: [dev] Main loop operation Hey! I'd be willing to look into this, but I'm almost certain that I'll need help :) I've tried the crude approach by wrapping socket() with ld's --wrap option and passing the file descriptor to libuv's uv_poll_*() APIs to add them to the main loop, and by calling OCProcess() whenever the intercepted sockets become readable. This has not worked :) OCProcess() was being called sometimes, sometimes not, but the bottom line is that the interaction between the client and the server wasn't happening. Since I'm quite unfamiliar with the code base, I would like to ask: Where are all the sources which need to be watched in order for an application to know when OCProcess() needs to be called? Are there sources other than sockets as well? I'll continue digging, but some guidance from a person more familiar with the code base than I would be most welcome :) HTH, Gabriel _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
