<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Sep 28, 2018 at 9:27 PM Michael Selik <<a href="mailto:mike@selik.org">mike@selik.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Sep 28, 2018 at 2:11 PM Sean Harrington <<a href="mailto:seanharr11@gmail.com" target="_blank">seanharr11@gmail.com</a>> wrote:<br>
> kwarg on Pool.__init__ called `expect_initret`, that defaults to False. When set to True:<br>
> Capture the return value of the initializer kwarg of Pool<br>
> Pass this value to the function being applied, as a kwarg.<br>
<br>
The parameter name you chose, "initret" is awkward, because nowhere<br>
else in Python does an initializer return a value. Initializers mutate<br>
an encapsulated scope. For a class __init__, that scope is an<br>
instance's attributes. For a subprocess managed by Pool, that<br>
encapsulated scope is its "globals". I'm using quotes to emphasize<br>
that these "globals" aren't shared.<br></blockquote><div><br></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_quote"><div>>> Yes - if you bucket the "initializer" arg of Pool into the "Python initializers" then I see your point here. And yes initializer mutates the global scope of the worker subprocess. Again, my gripe is not with globals. I am looking for the ability to have a clear, explicit flow of data from parent -> child process, without being constrained to using globals.</div></div></blockquote><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On Fri, Sep 28, 2018 at 4:39 PM Sean Harrington <<a href="mailto:seanharr11@gmail.com" target="_blank">seanharr11@gmail.com</a>> wrote:<br>
> On Fri, Sep 28, 2018 at 6:45 PM Antoine Pitrou <<a href="mailto:solipsis@pitrou.net" target="_blank">solipsis@pitrou.net</a>> wrote:<br>
>> 3. If you don't like globals, you could probably do something like<br>
>> lazily-initialize the resource when a function needing it is executed<br>
><br>
> if initializing the resource is expensive, we only want to do this ONE time per worker process.<br>
<br>
We must have a different concept of "lazily-initialize". I understood<br>
Antoine's suggestion to be a one-time initialize per worker process.<br></blockquote></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_quote"><div><br></div></div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_quote"><div>>> See my response to Anotoine earlier. I missed the point made. This is a valid solution to the problem of "initializing objects after a worker has been forked", but fails to address the "create big object in parent, pass to each worker". </div></div></blockquote><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On Fri, Sep 28, 2018 at 4:39 PM Sean Harrington <<a href="mailto:seanharr11@gmail.com" target="_blank">seanharr11@gmail.com</a>> wrote:<br>
> My simple argument is that the developer should not be constrained to make the objects passed globally available in the process, as this MAY break encapsulation for large projects.<br>
<br>
I could imagine someone switching from Pool to ThreadPool and getting<br>
into trouble, but in my mind using threads is caveat emptor. Are you<br>
worried about breaking encapsulation in a different scenario?<br></blockquote><div><br></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_quote"><div>>> Without a specific example on-hand, you could imagine a tree of function calls that occur in the worker process (even newly created objects), that should not necessarily have access to objects passed from parent -> worker. In every case given the current implementation, they will.</div></div></blockquote></div>