On Mon, Apr 20, 2020 at 2:22 PM Eric Snow <ericsnowcurrently@gmail.com> wrote:
On Sat, Apr 18, 2020 at 11:16 AM Antoine Pitrou <solipsis@pitrou.net> wrote:
* The "association" timing seems quirky and potentially annoying: an interpreter only becomes associated with a channel the first time it calls recv() or send(). How about, instead, associating an interpreter with a channel as soon as that channel is given to it through `Interpreter.run(..., channels=...)` (or received through `recv()`)?
That seems fine to me. I do not recall the exact reason for tying association to recv() or send(). I only vaguely remember doing it that way for a technical reason. If I determine that reason then I'll bring it up. In the meantime I'll update the PEP to associate interpreters when the channel end is sent.
FWIW, it may have been influenced by the automatic channel closing when no interpreters are associated. If interpreters are associated when channel ends are sent (rather than when used) then interpreters will have to be more careful about releasing channels. That's just a guess as to why I did it that way. :)
As I've gone to update the PEP for this I'm feeling less comfortable with changing it. There is a subtle difference which concretely manifests in 2 ways. Firstly, the programmatic exposure of "associated" (SendChannel.interpreters and RecvChannel.Interpreters) would be different. With the current specification, "associated" means "has been used by". With your recommendation it would mean "is accessible by". Is it more useful to think about them one way or the other? Would there be value in making both meanings part of the API separately ("associated" + "bound") somehow? Secondly, with the current spec channels get automatically closed sooner, effectively as soon as all wrapping objects *that were used* are garbage collected (or released). With your recommendation it only happens as soon all all wrapping objects are garbage collected (or released). In the former case channels could get auto-closed before you expect them to. In the latter case they could leak if users forget to release them when unused. Is there a good way to address both downsides? -eric