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 > > > > > > >
