>From what I've seen, the threading use is completely upside down. That is, the stack spawns its own threads to do work watching a few things in a blocking manner, with network config being the resource hog. That needs to be severely refactored but can be a separate issue.
>From my experience with such communication libs we really need to expose enough to allow the hosting app to provide the proper servicing, especially since the lower levels of the stack should not have enough information to make intelligent decisions. This also goes to making the stack easier to use, and especially so for testing or perhaps other edge use cases where more than a single stack instance is needed. Pushing out so that the hosting app can call an appropriate select() equivalent then push into the stack as needed can eliminate the need for internal threading and for odd sleep calls. This also frees us from the burden of trying to wrap mutexes, etc. Getting to a point where a single select() can do one watch for multiple stacks can make things very efficient. In essence it removes the decision of implementing thread pools from the stack and lets the hosting app drive things. It also would help integrate with various main loop or other solutions. On 04/07/2015 03:23 PM, Keane, Erich wrote: > 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 >>>>> >>>>> >>> >> > > _______________________________________________ > iotivity-dev mailing list > iotivity-dev at lists.iotivity.org > https://lists.iotivity.org/mailman/listinfo/iotivity-dev > -- Jon A. Cruz - Senior Open Source Developer Samsung Open Source Group jonc at osg.samsung.com
