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 -------------- 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/10c9fdac/attachment.p7s>