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