calls to .isdir and .isfile could block

[John Dickinson]

The various calls to .isdir, .isfile, and .getmtime (all from os.path) could block. They are from os.path and there isn't a green version from eventlet. Since they end up doing a stat on the file on disk, a tarpit disk would end up blocking the entire process.

Normally this probably isn't a problem, but it could be, especially for stuff like ring reloading in the proxy server.

Instead of reimplementing some green version of these methods, another solution would be to send them off to a threadpool.

[Samuel Merritt (torgomatic)]

You're never going to get a green version, either, thanks to how the syscalls for file IO work. There's no EWOULDBLOCK / EAGAIN for reading things like files or directories, so eventlet can't help.

I guess I could see doing the IO for a full ring reload in a threadpool, but it's only a few megs and it's only incurred when new rings show up. If the stat() every 15 seconds to determine ring freshness is noticeably damaging proxy throughput, then maybe using inotify() or something to watch for changes is a better approach. I certainly wouldn't want to kick every stat() out to a threadpool due to all the overhead.

[clayg (clay-gerrard)]

I think maybe we can mostly concern ourselves with data-drives and assume that if the os drive is being slow - well your hozed for other reasons less related to the robustness of our software? Maybe all ring reloading could be done in separate thread thread tho - esp if we're mostly concerning ourselves with object nodes. In fact now that error limiting was pulled out it may be the ring data structure is *always* read-only in all the workers/servers?