Watching breaks Ctrl+c about python-etcd3 HOT 5 OPEN

I don't think we should capture ctrl+c in this lib and cancel the watch.

As we had expose the cancel method to user, they should do it in their code.

from python-etcd3.

So it kinda works in python 3, but looking at grpc/grpc#6999, it seems upstream grpc people don't care. Maybe leaving this and documenting that it doesn't work in python 2 would be best.

from python-etcd3.

Oh, didn't know it's because of condition.wait()... I'm not a python expert, do we have something better to replace condition.wait()?

BTW, in one of my project, I start a daemon thread to watch the key change, But when the main thread exit, it print an error message said "segmentation fault". Not sure if related to the usage of condition.wait(), as the doc said daemon thread will exit if it's the only thread...

from python-etcd3.

This may be related, but it seems a bit more problematic. Thought about opening it as a separate issue, but I figured I would give it a try here instead.

I am running etcd3-0.9.0-py3.7 under python 3.7.1 on MacOS 10.13.6 (High Sierra).

As a demonstration, I have the following simple script:

import threading
import etcd3


etcd = etcd3.client()
result = etcd.watch_prefix_once("/")
print(str(result))
for t in threading.enumerate():
    print(str(t))
exit(0)

When I run this and then, in another window add a key "/foo" with a value of "value for /foo", what I see is:

$ python3 foo.py
<class 'etcd3.events.PutEvent'> key=b'/foo' value=b'value for foo'
<_MainThread(MainThread, started 140735995216768)>
<Thread(etcd3_watch_10b4cd748, started daemon 123145335029760)>
<Thread(Thread-1, started daemon 123145340284928)>
<Thread(Thread-2, started daemon 123145345540096)>

as expected, followed by a hang in exit that can only be cleared by a ^C.

This also happens if I am watching indefinitely, exit the watching loop and call cancel(), but the above is a simpler example. As you can see, the watch callback thread is still running after the completion of the watch_prefix_once() which may or may not be expected. That said, it is daemonized, so it should terminate when exit() is called.

I also tried adding a timeout to the watch_prefix_once() call, but that does not resolve the problem. The script still hangs indefinitely on exit, whether the timeout is hit during the call and exceptions out of the script or the call receives an event before the timeout is hit.

So far I have not been able to come up with a workaround for this. It appears that calling any flavor of watch permanently contaminates the process and it will not properly exit after that.

from python-etcd3.

It looks like my problem (described above) is a regression in 0.9.0-py3.7 because I don't see it when I install 0.8.1.

Also, another datapoint (related? not sure) I tried adding a call to etcd.close() (i.e. client.close()) before the exit in the example I showed, thinking this might be a workaround. When I do that, the watcher thread exceptions with a ValueError from grpc saying the channel is closed and then python locks up until I hit ^C. After the ^C, though, I am able to exit without hanging. Again, this is only in 0.9.0 as far as I can tell.

from python-etcd3.