<div dir="ltr">The implementation details need to be flushed out, but agnostic of these, do you believe this a valid solution to the initial problem? Do you also see it as a beneficial optimization to Pool, given that we don't need to store funcs/bound-methods/partials on the tasks themselves?<div><br></div><div>The latter concern about "what happens if `self` changed value in the parent" is the same concern as "what happens if `func` changes in the parent?" given the current implementation. This is an assumption that is currently made with Pool.map_async(func, ls). If "func" changes in the parent, there is no communication with the child. So one just needs to be aware that calling "map_async(self.func, ls)" while the state of "self" is changing, will not communicate changes to each worker. The state is frozen when Pool.map is called, just as is the case now.</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 12, 2018 at 9:07 AM Antoine Pitrou <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 12 Oct 2018 08:33:32 -0400<br>
Sean Harrington <<a href="mailto:seanharr11@gmail.com" target="_blank">seanharr11@gmail.com</a>> wrote:<br>
> Hi Nathaniel - this if this solution can be made performant, than I would<br>
> be more than satisfied.<br>
> <br>
> I think this would require removing "func" from the "task tuple", and<br>
> storing the "func" "once per worker" somewhere globally (maybe a class<br>
> attribute set post-fork?).<br>
> <br>
> This also has the beneficial outcome of increasing general performance of<br>
> Pool.map and friends. I've seen MANY folks across the interwebs doing<br>
> things like passing instance methods to map, resulting in "big" tasks, and<br>
> slower-than-sequential parallelized code. Parallelizing "instance methods"<br>
> by passing them to map, w/o needing to wrangle with staticmethods and<br>
> globals, would be a GREAT feature! It'd just be as easy as:<br>
> <br>
>     Pool.map(self.func, ls)<br>
> <br>
> What do you think about this idea? This is something I'd be able to take<br>
> on, assuming I get a few core dev blessings...<br>
<br>
Well, I'm not sure how it would work, so it's difficult to give an<br>
opinion.  How do you plan to avoid passing "self"?  By caching (by<br>
equality? by identity?)?  Something else?  But what happens if "self"<br>
changed value (in the case of a mutable object) in the parent?  Do you<br>
keep using the stale version in the child?  That would break<br>
compatibility...<br>
<br>
Regards<br>
<br>
Antoine.<br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/seanharr11%40gmail.com" rel="noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/seanharr11%40gmail.com</a><br>
</blockquote></div>