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 >
