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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7198 bytes Desc: not available URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150424/62a5193c/attachment.p7s>
