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
