" or since we're using glib anyway, GMainLoop?" I would prefer we move in the direction of weaning ourselves from glib rather than using it more, since we are aiming at tiny processors.
I believe there are simple solutions to the event loop issue that don't require hammers. John -----Original Message----- From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Thiago Macieira Sent: Tuesday, April 07, 2015 2:18 PM To: Keane, Erich Cc: iotivity-dev at lists.iotivity.org Subject: [dev] OCProcess & event loop (was: build sample application for sensors) On Tuesday 07 April 2015 13:32:56 Keane, Erich wrote: > The C++ SDK listeningFunc does that by necessity. The OCProcess > function is NOT thread safe (OCProcessPresence contains global state > which interferes with other calls). So these are required to be > protected from thread issues via by the caller. Since OCProcess is a > message-pump style call, it is necessary to call this often, so > listeningFunc does this in a loop. > > However, since OCProcess is NOT a blocking call, this will very > quickly cause performance issues if a sleep is not included. > Otherwise this loop manages to starve the rest of the stack. > > Sachin and I discussed making OCProcess be a blocking call at one > point, and had a good plan for how to do this (to make the sleep calls > unnecessary), however the implementation was tabled once the CA effort > began. It should be non-blocking. You touched the important point in the first paragraph: "it's necessary to call [OCProcess] often" *When?* How do I know that it is time to call it? We're missing a way to plug OCProcess into the application's main event loop. You said shortening the time of sleeps is a bad idea: correct, as that causes increased CPU usage and worse battery life since the CPU can't sleep for extended periods. But the longer the time is, the longer the delay of getting things done. Just take this pair of client and server examples: since both have sleep(2) calls, the time between a unicast request being sent and its reply being processed can be up to 4 seconds, which is at least 80x more than what it should (50 ms, and I'm being generous). Is there any API for getting the file descriptors and timers from the stack? Or a plan to add such functionality? Maybe instead we should use libev... or since we're using glib anyway, GMainLoop? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
