Author davin
Recipients davin, neologix, pitrou, sbt
Date 2015-04-18.20:58:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1429390680.36.0.641717992291.issue23992@psf.upfronthosting.co.za>
In-reply-to
Content
This is a nice example demonstrating what I agree is a problem with the current implementation of close.

A practical concern with what I believe is being proposed in your trivial fix:  if the workers are engaged in very long-running tasks (and perhaps slowly writing their overly large results to the results queue) then we would have to wait for quite a long time for these other workers to reach their natural completion.

That said, I believe close should in fact behave just that way and have us subsequently wait for the others to be completed.  It is not close's job to attempt to address the general concern I bring up.

This change could be felt by people who have written their code to expect the result handler's immediate shutdown if there are no other visible results -- it is difficult to imagine what the impact would be.

This is my long-winded way of saying it seems very sensible and welcome to me if you took the time to prepare a patch.
History
Date User Action Args
2015-04-18 20:58:00davinsetrecipients: + davin, pitrou, neologix, sbt
2015-04-18 20:58:00davinsetmessageid: <1429390680.36.0.641717992291.issue23992@psf.upfronthosting.co.za>
2015-04-18 20:58:00davinlinkissue23992 messages
2015-04-18 20:58:00davincreate