On May 24, 2010, at 5:36 AM, Brian Quinlan wrote: > On May 24, 2010, at 5:16 AM, Glyph Lefkowitz wrote: >> On May 23, 2010, at 2:37 AM, Brian Quinlan wrote: >>> On May 23, 2010, at 2:44 PM, Glyph Lefkowitz wrote:
> ProcessPoolExecutor has the same serialization perils that multiprocessing > does. My original plan was to link to the multiprocessing docs to explain > them but I couldn't find them listed. Linking to the pickle documentation might be a good start. > Yes, the execution context is Executor-dependent. The section under > ProcessPoolExecutor and ThreadPoolExecutor spells this out, I think. I suppose so. I guess I'm just looking for more precise usage of terminology. (This is a PEP, after all. It's a specification that multiple VMs may have to follow, not just some user documentation for a package, even if they'll *probably* be using your code in all cases.) I'd be happier if there were a clearer term than "calls" for the things being scheduled ("submissions"?), since the done callbacks aren't called in the subprocess for ProcessPoolExecutor, as we just discussed. >> Sure. Really, almost any contract would work, it just needs to be spelled >> out. It might be nice to know whether the thread invoking the callbacks is >> a daemon thread or not, but I suppose it's not strictly necessary. > > Your concerns is that the thread will be killed when the interpreter exits? > It won't be. Good to know. Tell it to the PEP though, not me ;). >> No reaction on [invoker vs. future]? I think you'll wish you did this in a >> couple of years when you start bumping into application code that calls >> "set_result" :). > > My reactions are mixed ;-) Well, you are not obliged to take my advice, as long as I am not obliged to refrain from mocking you mercilessly if it happens that I was right in a couple of years ;-). > Your proposal is to add a level of indirection to make it harder for people > to call implementation methods. The downside is that it makes it a bit harder > to write tests and Executors. Both tests and executors will still create and invoke methods directly on one object; the only additional difficulty seems to be the need to type '.future' every so often on the executor/testing side of things, and that seems a cost well worth paying to avoid confusion over who is allowed to call those methods and when. > I also can't see a big problem in letting people call set_result in client > code though it is documented as being only for Executor implementations and > tests. > > On the implementation side, I don't see why an Invoker needs a reference to > the future. Well, uh... > class Invoker(object): > def __init__(self): > """Should only be called by Executor implementations.""" > self.future = Future() ^ this is what I'd call a "reference to the future"
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com