"Do you believe that we can incrementally improve thread handling?"
Emphatically, yes. My comment on the Ethernet/Wifi thread shows a way to simplify this new code by eliminating the thread pool at the bottom in CAReceiveHandler. An entire thread pool! Besides eliminating the thread pool, it simplifies the code, especially with the application of IOT-496, and prepares for easier adoption of IPv6. John -----Original Message----- From: Lankswert, Patrick Sent: Friday, April 24, 2015 10:14 AM To: Light, John J; Keane, Erich; iotivity-dev at lists.iotivity.org Subject: RE: GLib removal and thread-pool implementation- John, I generally agree in principle. However, I think that the step function of bring CA online was expensive to the project. I want to avoid another step function. Do you believe that we can incrementally improve thread handling? Pat > -----Original Message----- > From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev- > bounces at lists.iotivity.org] On Behalf Of Light, John J > Sent: Friday, April 24, 2015 11:16 AM > To: Keane, Erich; iotivity-dev at lists.iotivity.org > Subject: Re: [dev] GLib removal and thread-pool implementation- > > Comments? You asked. > > We should be working to eliminate all the thread pools. All of the thread > pools in current master, including the connectivity abstraction, are > unnecessary and have no real affect other than to complicate the code and > create difficult problems. I submit without proof that running IoTivity on two > threads (main process and application callbacks, in addition to application > thread), would provide all the functional and performance advantages we > now generate from all the threads and thread pools we now have. I believe > that, in a rational development environment, all the extra threading should > have to be justified. Instead, I find that I must argue for fewer threads. > > Spending more effort to eliminate threads and less to make them palatable > would have a bigger positive effect on IoTivity. > > John Light > Intel OTC OIC development > > > -----Original Message----- > From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev- > bounces at lists.iotivity.org] On Behalf Of Keane, Erich > Sent: Thursday, April 23, 2015 2:18 PM > To: iotivity-dev at lists.iotivity.org > Subject: [dev] GLib removal and thread-pool implementation- > > Hi all- > As many know, I've been working to remove glib as a compilation > dependency for non-tizen systems. I've done this in review 747: > https://gerrit.iotivity.org/gerrit/#/c/747 > > My concern is with my threadpool implementation. The implementation in > 747 is merely a dispatcher, starting and detaching a thread when requested. > > After analyzing the code, it seems like this should be sufficient, however a > few comments have been made on the review that disagree. I wanted to > extract that conversation here for further discussion. > > Another alternative that I thought of based on Ashok's feedback is an > unlimited pool-thread system (essentially functionally like the glib > implementation, since the thread_count is greater than requested threads), > where the threads list is stored in an array list, then can be joined at the end. > I'm not sure what that buys us other than blocking until all threads have been > completed, but Ashok's comments seem to believe that it is a necessity. > > So, thoughts/comments? > -Erich > _______________________________________________ > iotivity-dev mailing list > iotivity-dev at lists.iotivity.org > https://lists.iotivity.org/mailman/listinfo/iotivity-dev > _______________________________________________ > iotivity-dev mailing list > iotivity-dev at lists.iotivity.org > https://lists.iotivity.org/mailman/listinfo/iotivity-dev
