Our biggest CPU intensity currently is watching the ethernet/wifi adapters for change and JSON parsing/generation. Otherwise we are pretty low-hit.
I agree that a solid audit to remove a bunch of the threading would be a great feature as well, but I suspect that SOME threading would be necessary, but it could definitely make the glib2 less necessary. On Tue, 2015-04-07 at 22:16 +0000, Light, John J wrote: > I wasn?t going to mention that, but now that you did... > > The only CPU intensive parts of IoTivity are DTLS and (less so) PDU creation. > The I/O is only mildly overlapped. > > The need for multiple threads isn't performance or throughput. There's a > small latency play, but I don't think it's critical. > > If you believe me on that, the only reasons we have threads at all are: > * disconnect the application from the I/O, and > * as a crutch to separate function. > > The former is worthy, and we should preserve it when threads are available. > The other isn't, and only complicate maintenance, bug fix, and adding new > capabilities. > > If we eliminated most of the threading, we could drop glib and have a better > code base going forward. > > John > > -----Original Message----- > From: Keane, Erich > Sent: Tuesday, April 07, 2015 3:07 PM > To: Light, John J > Cc: iotivity-dev at lists.iotivity.org; Macieira, Thiago; Lenahan, Charlie > Subject: Re: [dev] OCProcess & event loop (was: build sample application for > sensors) > > An additional thing we could investigate is how many of those mutexes and > threads are actually necessary. A good atomics implementation could save us > a bunch of locking in a number of cases IIRC. > > > On Tue, 2015-04-07 at 22:04 +0000, Light, John J wrote: > > I've been swimming in CA for a couple of months now, and I can't see any > > need for thread pools. We just need another threading design, and we can > > eliminate glib and the 'singlethread' versions in one fell swoop. > > > > John > > > > > > -----Original Message----- > > From: Keane, Erich > > Sent: Tuesday, April 07, 2015 2:48 PM > > To: Lenahan, Charlie > > Cc: iotivity-dev at lists.iotivity.org; Macieira, Thiago; Light, John J > > Subject: Re: [dev] OCProcess & event loop (was: build sample > > application for sensors) > > > > I agree, glib2 has been a bit of a pain. Implementing a > > mutex/thread/threadpool in a multi-platform solution is quite a task > > however, and I would much rather find a solid library to do these things > > rather than implement and maintain them ourselves. > > > > > > On Tue, 2015-04-07 at 21:46 +0000, Lenahan, Charlie wrote: > > > I'd throw my hat in the remove glib camp too. > > > > > > On 4/7/15, 5:28 PM, "Light, John J" <john.j.light at intel.com> wrote: > > > > > > >" 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 > > > > > > > > > > >
