As suggested by https://packaging.python.org/guides/making-a-pypi-friendly-readme/ and https://github.com/pypa/warehouse/issues/3884#issuecomment-386188844, this may now be necessary on warehouse.

Adding it to setup.py results in 'distutils/dist.py:274: UserWarning: Unknown distribution option: 'long_description_content_type'' even with setuptools 39, but setup.cfg is equivalent. I verified that PKG-INFO has the appropriate 'Description-Content-Type: text/x-rst' field.

Queue all libuv callbacks and run them at the end of the iteration

Invalid FDs were getting through because of the order in which we ran loop callbacks.

This solves the timer delay. Add a specific test for this.

We're still sensitive to exactly when these run, for reasons that
aren't clear (comment inline). I want to spend some more time
investigating that.

This disables user-access to prepare watchers on libuv (otherwise
we're right back where we started). It could be worked around if
needed without *too* much trouble.

This should eliminate the need to patch and the need to avoid 0 duration timers.

This works more like libev. We could theoretically implement priorities using this system.

lock: fix typo [skip ci]

It just bothers me so much whenever I hit it, sorry

Compile the monitor greenlet tracer with Cython

This makes things 54% faster. In fact, the monitor tracer is now faster than a trivial tracer implemented in python (settrace(lambda e, a: None)).

+-------------------+-----------------+-----------------------------+
| Benchmark         | 37_bench_tracer | 37_bench_tracer_cython_opt3 |
+===================+=================+=============================+
| monitor tracer    | 1.62 us         | 739 ns: 2.20x faster (-54%) |
+-------------------+-----------------+-----------------------------+
| max switch tracer | 3.06 us         | 874 ns: 3.50x faster (-71%) |
+-------------------+-----------------+-----------------------------+
| hub switch tracer | 2.16 us         | 815 ns: 2.66x faster (-62%) |
+-------------------+-----------------+-----------------------------+

Not significant (2): no tracer; trivial tracer

Unoptimized still makes them 25% faster:

+-------------------+-----------------+------------------------------+
| Benchmark         | 37_bench_tracer | 37_bench_tracer_first_cython |
+===================+=================+==============================+
| trivial tracer    | 792 ns          | 786 ns: 1.01x faster (-1%)   |
+-------------------+-----------------+------------------------------+
| monitor tracer    | 1.62 us         | 1.24 us: 1.31x faster (-24%) |
+-------------------+-----------------+------------------------------+
| max switch tracer | 3.06 us         | 1.89 us: 1.62x faster (-38%) |
+-------------------+-----------------+------------------------------+
| hub switch tracer | 2.16 us         | 1.68 us: 1.29x faster (-22%) |
+-------------------+-----------------+------------------------------+

Current numbers on 3.7b3:

no tracer: Mean +- std dev: 414 ns +- 10 ns
trivial tracer: Mean +- std dev: 792 ns +- 16 ns
monitor tracer: Mean +- std dev: 1.62 us +- 0.12 us
max switch tracer: Mean +- std dev: 3.06 us +- 0.12 us
hub switch tracer: Mean +- std dev: 2.16 us +- 0.04 us

Fix a typo [skip ci]

Make the libuv run QUEUE part of the loop.

Benchmarking (link in the email) showed that malloc/free had substantial and widely varying overhead.

I didn't really see much of a difference in the gevent benchmarks, but I didn't run them all. However, if any patch gets upstreamed, it will probably be something like this.

The link referenced in the email contains the discussion on the libuv mailing list.

* Make the monitor thread survive a fork.

* Add coverage for the new get_process.

* psutil is not on windows, move the test to a protected location.

* No, really.

Add gevent.util.assert_switches 

Based on refactoring existing code in _monitor.py

Flexibly allows checking for any switching, switches that take longer
than a set amount of time, or switches that exceed a time limit
between getting back to the hub.

Fixes #1182.

Update to libuv 1.20.1

Update libuv to 1.20

We're more competitive using a forked process:

.....................
gevent socketpair sendall greenlet: Mean +- std dev: 256 ms +- 6 ms
.....................
native socketpair sendall thread: Mean +- std dev: 44.4 ms +- 1.5 ms
.....................
WARNING: the benchmark result may be unstable
* the standard deviation (7.31 ms) is 13% of the mean (57.9 ms)
* the maximum (89.0 ms) is 54% greater than the mean (57.9 ms)

Try to rerun the benchmark with more runs, values and/or loops.
Run 'python -m perf system tune' command to reduce the system jitter.
Use perf stats, perf dump and perf hist to analyze results.
Use --quiet option to hide these warnings.

gevent socketpair sendall fork: Mean +- std dev: 57.9 ms +- 7.3 ms
.....................
native socketpair sendall fork: Mean +- std dev: 44.6 ms +- 2.0 ms
.....................
native udp sendto: Mean +- std dev: 30.6 ms +- 1.1 ms
.....................
gevent udp sendto: Mean +- std dev: 37.5 ms +- 2.7 ms

(python 3.7)

This addresses the first few points of #1060.

We now have a basic documentation for what a loop looks like, and we
have documented watcher.close()

Hub is better documented (only the parts that should be documented are
documented).

get/setswitchinterval is documnted.

Several xrefs are fixed up.

Sigh. Pip changed the semantics of -U in pip 10. go back to the old way so we're actually testing changing deps; if it breaks we need to know.

Use /dev/fd|/proc/self/fd to get open FDs to close in Popen

Should get them to complete coverage.

Also move our test dependencies into the standard 'test' extra and
install mock (and futures) only on Python 2.7.

If those aren't available, use the old brute-force approach. This is
closer to what CPython does in its C implementation, and is much
faster.

We don't have to worry about the async signal safe stuff the C code
does because, guess what, we're running Python code here already
anyway, so much of it could wind up doing something that's not
actually safe anyway. Oh well.

Since we depend on Python 3.4 and above now, we can rely on the
CLOEXEC flag being set by default and not have to manually check
everything.

This speeds up 2.7 (close_fds defaults to *false* there, so the
default case doesn't change):

| Benchmark                 | 27_bench_subprocess | 27_bench_subprocess_dirfd     |
+---------------------------+---------------------+-------------------------------+
| spawn native no close_fds | 1.81 ms             | 1.79 ms: 1.01x faster (-1%)   |
| spawn gevent no close_fds | 2.11 ms             | 2.20 ms: 1.04x slower (+4%)   |
| spawn native close_fds    | 31.0 ms             | 30.2 ms: 1.03x faster (-3%)   |
| spawn gevent close_fds    | 31.6 ms             | 2.56 ms: 12.31x faster (-92%) |

And it really speeds up 3.7 (close_fds defaults to *true* there, so
the default case is much faster, and the non-default case is even better):

| Benchmark                 | 37_bench_subprocess | 37_bench_subprocess_dirfd     |
+---------------------------+---------------------+-------------------------------+
| spawn native no close_fds | 1.34 ms             | 1.27 ms: 1.06x faster (-6%)   |
| spawn gevent no close_fds | 117 ms              | 3.05 ms: 38.27x faster (-97%) |
| spawn native close_fds    | 1.36 ms             | 1.30 ms: 1.04x faster (-4%)   |
| spawn gevent close_fds    | 32.5 ms             | 3.34 ms: 9.75x faster (-90%)  |

Fixes #1172