From 94e52b13e62e273ea0b89ca3a628a357a5769a5a Mon Sep 17 00:00:00 2001 From: Jason Madden Date: Fri, 15 Jan 2021 16:06:13 -0600 Subject: [PATCH] Preparing release 21.1.0 --- CHANGES.rst | 55 +++++++++++++++++++++++++++++++++++++++ docs/changes/1739.misc | 25 ------------------ docs/changes/1745.bugfix | 10 ------- src/gevent/__init__.py | 2 +- src/gevent/_interfaces.py | 2 +- src/gevent/monkey.py | 2 +- 6 files changed, 58 insertions(+), 38 deletions(-) delete mode 100644 docs/changes/1739.misc delete mode 100644 docs/changes/1745.bugfix diff --git a/CHANGES.rst b/CHANGES.rst index cfd92342d..588d553d6 100644 --- a/CHANGES.rst +++ b/CHANGES.rst @@ -6,6 +6,61 @@ .. towncrier release notes start +21.1.0 (2021-01-15) +=================== + + +Bugfixes +-------- + +- Make gevent ``FileObjects`` more closely match the semantics of native + file objects for the ``name`` attribute: + + - Objects opened from a file descriptor integer have that integer as + their ``name.`` (Note that this is the Python 3 semantics; Python 2 + native file objects returned from ``os.fdopen()`` have the string + "" as their name , but here gevent always follows Python 3.) + - The ``name`` remains accessible after the file object is closed. + + Thanks to Dan Milon. + See :issue:`1745`. + + +Misc +---- + +Make ``gevent.event.AsyncResult`` print a warning when it detects improper +cross-thread usage instead of hanging. + +``AsyncResult`` has *never* been safe to use from multiple threads. +It, like most gevent objects, is intended to work with greenlets from +a single thread. Using ``AsyncResult`` from multiple threads has +undefined semantics. The safest way to communicate between threads is +using an event loop async watcher. + +Those undefined semantics changed in recent gevent versions, making it +more likely that an abused ``AsyncResult`` would misbehave in ways +that could cause the program to hang. + +Now, when ``AsyncResult`` detects a situation that would hang, it +prints a warning to stderr. Note that this is best-effort, and hangs +are still possible, especially under PyPy 7.3.3. + +At the same time, ``AsyncResult`` is tuned to behave more like it did +in older versions, meaning that the hang is once again much less +likely. If you were getting lucky and using ``AsyncResult`` +successfully across threads, this may restore your luck. In addition, +cross-thread wakeups are faster. Note that the gevent hub now uses an +extra file descriptor to implement this. + +Similar changes apply to ``gevent.event.Event`` (see :issue:`1735`). + +See :issue:`1739`. + + +---- + + 20.12.1 (2020-12-27) ==================== diff --git a/docs/changes/1739.misc b/docs/changes/1739.misc deleted file mode 100644 index be957f368..000000000 --- a/docs/changes/1739.misc +++ /dev/null @@ -1,25 +0,0 @@ -Make ``gevent.event.AsyncResult`` print a warning when it detects improper -cross-thread usage instead of hanging. - -``AsyncResult`` has *never* been safe to use from multiple threads. -It, like most gevent objects, is intended to work with greenlets from -a single thread. Using ``AsyncResult`` from multiple threads has -undefined semantics. The safest way to communicate between threads is -using an event loop async watcher. - -Those undefined semantics changed in recent gevent versions, making it -more likely that an abused ``AsyncResult`` would misbehave in ways -that could cause the program to hang. - -Now, when ``AsyncResult`` detects a situation that would hang, it -prints a warning to stderr. Note that this is best-effort, and hangs -are still possible, especially under PyPy 7.3.3. - -At the same time, ``AsyncResult`` is tuned to behave more like it did -in older versions, meaning that the hang is once again much less -likely. If you were getting lucky and using ``AsyncResult`` -successfully across threads, this may restore your luck. In addition, -cross-thread wakeups are faster. Note that the gevent hub now uses an -extra file descriptor to implement this. - -Similar changes apply to ``gevent.event.Event`` (see :issue:`1735`). diff --git a/docs/changes/1745.bugfix b/docs/changes/1745.bugfix deleted file mode 100644 index 4ee68b708..000000000 --- a/docs/changes/1745.bugfix +++ /dev/null @@ -1,10 +0,0 @@ -Make gevent ``FileObjects`` more closely match the semantics of native -file objects for the ``name`` attribute: - -- Objects opened from a file descriptor integer have that integer as - their ``name.`` (Note that this is the Python 3 semantics; Python 2 - native file objects returned from ``os.fdopen()`` have the string - "" as their name , but here gevent always follows Python 3.) -- The ``name`` remains accessible after the file object is closed. - -Thanks to Dan Milon. diff --git a/src/gevent/__init__.py b/src/gevent/__init__.py index 56a68cdf5..2b4b6abe9 100644 --- a/src/gevent/__init__.py +++ b/src/gevent/__init__.py @@ -27,7 +27,7 @@ #: Use ``pkg_resources.parse_version(__version__)`` or #: ``packaging.version.Version(__version__)`` to get a machine-usable #: value. -__version__ = '20.12.2.dev0' +__version__ = '21.1.0' __all__ = [ diff --git a/src/gevent/_interfaces.py b/src/gevent/_interfaces.py index 05a5051f7..f41f461e5 100644 --- a/src/gevent/_interfaces.py +++ b/src/gevent/_interfaces.py @@ -243,7 +243,7 @@ def run_callback_threadsafe(func, *args): loop to notice that the *func* has been scheduled (e.g., it causes the loop to wake up). - .. versionadded:: NEXT + .. versionadded:: 21.1.0 .. seealso:: :meth:`asyncio.loop.call_soon_threadsafe` The :mod:`asyncio` equivalent. diff --git a/src/gevent/monkey.py b/src/gevent/monkey.py index 56a23293d..2f6641fec 100644 --- a/src/gevent/monkey.py +++ b/src/gevent/monkey.py @@ -239,7 +239,7 @@ def is_anything_patched(): # it is 100% reliable in the event of third-party patch functions that # don't use ``saved``. # - # .. versionadded:: NEXT + # .. versionadded:: 21.1.0 return bool(saved)