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>

Reply via email to