Author dan.oreilly
Recipients andreasvc, bquinlan, dan.oreilly, giampaolo.rodola, josh.r, mark.dickinson, mdengler, pitrou
Date 2014-08-11.02:51:42
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1407725503.18.0.764854029351.issue21423@psf.upfronthosting.co.za>
In-reply-to
Content
> It seems the addition of the initargs argument doesn't tackle Mark's objection here:

> > the initialiser and uninitialiser for the EnhancedThreadPoolExecutor
> > accept no arguments. In retrospect, it would have been better to have 
> > them take the thread itself as a single argument.

This would be inconsistent with multiprocessing.Pool's initializer/initargs behavior. I'm not sure if consistency is important there or not, but its worth pointing out.

I'm also not sure how useful it would be for ProcessPoolExecutor to receive an instance of itself. With multiprocessing.Pool,  initializer is a commonly used to pass objects that can only be inherited to workers (Queues, Locks, etc.). The same pattern would be useful for ProcessPoolExecutor, which means initializer needs to be able to take an arbitrary number of arguments, rather than just an instance to the Process object itself.
History
Date User Action Args
2014-08-11 02:51:43dan.oreillysetrecipients: + dan.oreilly, bquinlan, mark.dickinson, pitrou, giampaolo.rodola, mdengler, josh.r, andreasvc
2014-08-11 02:51:43dan.oreillysetmessageid: <1407725503.18.0.764854029351.issue21423@psf.upfronthosting.co.za>
2014-08-11 02:51:43dan.oreillylinkissue21423 messages
2014-08-11 02:51:42dan.oreillycreate