Dave C <dave.zap@gmail.com> writes:
With you help I was able to get the whole thing working this afternoon, although I will need to spend a lot more time testing and checking I've caught all the traps.
Ok, great!
The core application uses edge triggered epoll for the sake of efficiency and so far I have not found any problems running the queries now with the non-blocking API.
Yes, I agree edge-triggered is a good way, and it is supposed to work (and if you should find something that does not, I'll fix it).
At this point it's simple so I'm only checking POLLIN as that seems to work for the connect and query and fetch_row that I'm going.
I guess the MYSQL_WAIT_TIMEOUT is not being passed because I've just not run in to that case yet, but will unset it as you mention before passing it to _cont()
The timeout on epoll_wait() is set to 1 second, but we never reach that due the amount of traffic. One second is the max because we must service other things no later then that, for things such as automatically destroying non responsive sockets after 30 seconds, including the MariaDB ones. The case of queries that timeout can be handled in the same way, or else I can check for standard mysql error codes?
Yes, I think you can handle it the same way. It is probably safe to ignore MYSQL_WAIT_TIMEOUT completely. Then the MYSQL_OPT_*_TIMEOUT options for mysql_options() will do nothing, but if you handle non responsive sockets differently anyway, that might be fine.
Thanks again for your help. If I find anything weird I'll drop a post here, but more often then not the weirdness is on my side.
One interesting side effect of passing 0 to _cont() functions was the multitude of segfaults I was getting on other random / unrelated functions I'll see If I can replicate that once I've bedded everything down.
- Kristian.