Use in-memory notifications for workers

[rbranson]

Changes the interprocess notifications for workers to use an in-memory multiprocessing.Value instead of changing a filesystem timestamp, which requires interaction with the filesystem and can face contention issues or I/O related bottlenecks. The changed code doesn't require any platform-specific logic because it doesn't deal directly with any platform-related idiosyncrasies. multiprocessing.Value uses shared memory under the hood in most cases so it is very efficient.

I ran a load test using "hey" against a gunicorn with a hello world app wrapped in strace -c to measure the syscall impact.

top 5 strace summary before:

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 26.44    2.092495          20    100000           sendto
 14.22    1.125266          20     53774           close
 13.79    1.091552           6    160582           utimensat
 11.78    0.931931           9    100001           getsockname
 11.76    0.930716           8    105291     55291 accept4

top 5 strace summary after:

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 25.83    2.058187          20    100000           sendto
 17.56    1.399223          20     67596         1 pselect6
 14.53    1.157935           9    117570     67570 accept4
 14.25    1.135567          22     50619           close
 10.89    0.867693           8    100001           getsockname

[pajod]

I wonder if (in the O_TMPFILE and in the shm case) converting to floating point and back is needlessly weird.. We are reading the clock as a nanosecond-precision unsigned integer, are we not?

[rbranson]

time.monotonic returns a float: https://docs.python.org/3/library/time.html#time.monotonic

[pajod]

By not using the _ns variant we ask for it. No bug, just.. why ask for binary64 (@d) to store uint64 (=Q)?

[rbranson]

'd' is a double floating point encoding, not binary64. I'm not sure what you mean by asking for it.

[pajod]

That is an implicit ctypes dependency again, right?

[rbranson]

That is an implicit ctypes dependency again, right?

multiprocessing uses ctypes internally to expose shared memory as a Python object. It doesn't create any dependencies beyond the Python stdlib and any platform differences are handled within.

[benoitc]

The idea is good b ut I think there is a better way than using a shared value . We could instead use an atomic integer there. I will suggest an alternative asap. Let keep this PR open anyway yo compare the reult and safety.

[rbranson]

The idea is good b ut I think there is a better way than using a shared value . We could instead use an atomic integer there. I will suggest an alternative asap. Let keep this PR open anyway yo compare the reult and safety.

FWIW, I thought about using a sequence number but this was a more straightforward change, and I couldn't come up with a substantial enough reason it was better. Fewer calls to get the clock?