At the moment, the idea is to eliminate the feature from the implementation, and re-implement as necessary. I chose to do this based on our current use case. We currently use the number 20, yet only start ~16 threads, so we are effectively using the thread-pool as a detach method.
On Mon, 2015-04-27 at 10:39 +0000, ASHOKBABU CHANNA wrote: > Dear Erich, > > Detached threads with Join of all threads eliminate current usage of > glib dependency. (Part of glib feature) > > > > But as you know with thread pool, we can make configurable number > threads (for ex: 3-4 or 10-12) for any number of runtime tasks by just > adding it to queue. > > > > Are we eliminating this feature altogether? If not how we are going to > map this functionality? > > Making thread pool is not easy task with pthreads. > > > > Regards, > Ashok > > ------- Original Message ------- > > Sender : Keane, Erich<erich.keane at intel.com> > > Date : Apr 25, 2015 06:29 (GMT+09:00) > > Title : Re: [dev] GLib removal and thread-pool implementation- > > > > Hi Pat/all: > > I've put together review 832: > https://gerrit.iotivity.org/gerrit/#/c/832 > that is based on my other version at 747: > https://gerrit.iotivity.org/gerrit/#/c/747 that seems to be what Ashok > was looking for. > > I'm curious for the community's feedback as to the > necessity/requirements of each. > > -Erich > > On Fri, 2015-04-24 at 17:38 +0000, Lankswert, Patrick wrote: > > Erich, > > > > Hmmm... when you tell a thread to stop, how do you know what you can > free any > > resources (memory and mutexes) that the thread accesses without > join(). All > > the options that I can think of involve a lot more code. > > > > :( > > > > Pat > > > > > -----Original Message----- > > > From: Keane, Erich > > > Sent: Friday, April 24, 2015 1:35 PM > > > To: Lankswert, Patrick > > > Cc: iotivity-dev at lists.iotivity.org; Macieira, Thiago > > > Subject: Re: [dev] GLib removal and thread-pool implementation- > > > > > > The current use case doesn't actually need an explicit > "Join". The > > > interface > > > that is currently being used is: > > > > > > CreateTP > > > Start Task > > > DestroyTP > > > > > > The glib implementation uses the glib2 ThreadPool, which > on-destroy does > > > an explicit "Join" of each thread, which we call on shutdown of > the stack. > > > > > > My "dumb" implementation does the following: > > > CreateTP: No-Op > > > Start Task: Create thread, detach it (auto-cleans up) Destroy TP: > No-Op > > > > > > The alternative I see that is potentially useful, though I've seen > no > > > evidence > > > of its usefulness is: > > > Create TP: Start an ArrayList to hold thread IDs Start Task: > Create thread, > > > add > > > it to the array list Destroy TP: "Join" all the threads. > > > > > > > > > > > > On Fri, 2015-04-24 at 17:10 +0000, Lankswert, Patrick wrote: > > > > Erich, > > > > > > > > I think that the creator of a thread should be able to manage it > to > > > > termination aka join. So, the handle of thread is necessary. I > would > > > > prefer that we not expose a method to halt a thread like > > > > pthread_cancel() since it is rarely done correctly. > > > > > > > > Pat > > > > > > > > > -----Original Message----- > > > > > From: iotivity-dev-bounces at lists.iotivity.org > [mailto:iotivity-dev- > > > > > bounces at lists.iotivity.org] On Behalf Of Keane, Erich > > > > > Sent: Friday, April 24, 2015 12:38 PM > > > > > To: Macieira, Thiago > > > > > Cc: iotivity-dev at lists.iotivity.org > > > > > Subject: Re: [dev] GLib removal and thread-pool > implementation- > > > > > > > > > > On Fri, 2015-04-24 at 00:02 -0700, Thiago Macieira wrote: > > > > > > On Thursday 23 April 2015 21:18:11 Keane, Erich wrote: > > > > > > > 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. > > > > > > > > > > > > Please don't implement our own thread pool mechanism. From > > > > > > experience with doing QThreadPool, it's a nightmare to get > right > > > > > > and fix all the race conditions associated with idle threads > exiting. > > > > > > > > > > > > If you do need to implement a pool, then do not expire > threads: > > > > > > let them run forever, once started. > > > > > > > > > > I agree, ThreadPools are a nightmare, which is why I > implemented the > > > > > 'dispatch and detach' mechanism in the 'dumb' version. I > think the > > > > > only change I would make if absolutely necessary would be to > store > > > > > the > > > > thread_id > > > > > in an arraylist so that we can Join them all at the end, which > > > > > Ashok's comments suggest is necessary. > > > > > _______________________________________________ > > > > > 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 > > > > > > > > > >
