-
Notifications
You must be signed in to change notification settings - Fork 554
Disconnect issue #4
Comments
On which example: redis_client, redis_subscriber or both of them? |
Both of them. Using g++ (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4. |
Mmh, if it was only in the redis_subscriber, the problem may have been caused by a compiler optimization because the But if it is on both examples, then I will need to check my implementation. Does it happen every time? |
Yes, it happens every time on my machine in both examples. I've also tried volatile etc. but no avail so far. I also notice the main thread appears to get suspended upon disconnection. If I output the should_exit value to stderr inside the loop I notice the output stops. |
Ok, I finally managed to reproduce the issue. It never happens on my mac, but I got it sometimes (maybe 10% of the time) on a debian VM. I've localised the issue in the tcp client. It's a similar problem that the one reported in #3: sometimes the conditional variable is locked after having been notified by the other thread. I should patch it this evening if I have the time. |
I've added atomic variables to avoid waiting if conditional variable has already been notified. Could you please tell me if everything is ok now? Or if the problem is still there for you? |
The redis_client example is working now, but the redis_subscriber example still hangs on interrupt. However, making the should_exit variable in this example volatile std::atomic_bool (which is the type the redis_client uses) seems to do the trick! Thanks! |
…oid compiler optimization (which leads to infinite loop at exit)
Oh, yes, I've forgotten to commit this! This is now done, I close the issue. Thank you again for your help :) |
There is a disconnect issue in the examples that puzzles me. The sigint_handler and the subsequent disconnection handler are invoked upon sending the interrupt signal, but the main function does not terminate.
Adding a sleep(1) inside the "while (not should_exit);" loop appears to solve the termination issue, but is there possibly a disconnect/threading issue at play here?
Thank you for a nice Redis client!
The text was updated successfully, but these errors were encountered: