Closed millerdev closed 4 years ago
Thank you for reporting this. Which Python version did you use to run into this? CPython 3.8, on Linux?
CPython 3.7 on macOS. The close()
method was added in 3.7
Gotcha, thanks, I'll look into that!
Edit: so far on MacOS CI tests:
Mac OS X tests (all with gevent 1.3.x):
pyenv Python builds: CPython 2.7, 3.6, PyPy3
system CPython
That's one reason how we didn't notice this so far.
Will need to change that, too, obviously.
I felt free to rename this issue. Did a bit of CI maintenance work (https://github.com/jgehrcke/gipc/pull/91) that will allow for confidently adding support for the close()
method to gipc.
We cannot call the original .close()
method, as outlined in the gipc code base, because that will invoke a wait()-like system call -- which would conflict with the libev child watcher's mechanism.
My plan is, I think, to provide a close() implementation very close to what the original does.
Working on this in https://github.com/jgehrcke/gipc/pull/93
@millerdev I just released gipc 1.1.0 which should resolve this. If you can, please give it a quick test! Thank you!
gipc processes started with
proc = start_process(...)
always error onproc.close()
:ValueError: Cannot close a process while it is still running. You should first call join() or terminate().
The problem is that
_GProcess
patches_popen.poll
to returnNone
:https://github.com/jgehrcke/gipc/blob/e79845d6af4f6c574eb344b1c7d3aa2c421d255b/gipc/gipc.py#L448
This breaks the implementation of
multiprocessing.Process.close
, which raises an error if_popen.poll()
returnsNone
.