Henrique Andrade <h...@unscrambl.com> added the comment: I don't want to "close the pipes but maintain the queue alive" - I want to terminate the queue and make sure that no resources are leaked. It's that simple.
When one closes a file or a socket, there is no underlying OS resource being held. That's what I would like to have here too. Apparently the design does not support that and, if that's the case, it's fine, it's just that it goes against most of the norm afaict. On Sun, Mar 18, 2018 at 12:46 PM, Pablo Galindo Salgado < rep...@bugs.python.org> wrote: > > Pablo Galindo Salgado <pablog...@gmail.com> added the comment: > > Notice that the documentation for close says: > > > Indicate that no more data will be put on this queue by the current > process. The background thread will quit once it has flushed all buffered > data to the pipe. This is called automatically when the queue is garbage > collected. > > The method does not promise to close any pipe, just "Indicate that no more > data will be put on this queue by the current process". Closing prematurely > the writer side could lead to issues. I still do not understand why you > would want to close the pipes but maintain the queue alive. > > I could be missing something, so let's see if other people think > differently about this. > > ---------- > > _______________________________________ > Python tracker <rep...@bugs.python.org> > <https://bugs.python.org/issue33081> > _______________________________________ > -- Henrique Andrade | +1-530-426-2123 | h...@unscrambl.com | https://unscrambl.com ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33081> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
