Skip to content

bpo-38314: Add is_reading() method to asyncio _UnixReadPipeTransport #17042

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 35 commits into from

Conversation

calluw
Copy link
Contributor

@calluw calluw commented Nov 4, 2019

Unix read pipe (from Lib:asyncio.unix_events) is missing is_reading() method available for other read transports within the asyncio protocol, which checks that the transport read is not
paused or the transport is not closing.

This behaviour is documented in Doc/library/asyncio-protocol.rst.

Additional tests for the Lib:asyncio.unix_events module which check against the state of the pipe and the behaviour of is_reading().

https://bugs.python.org/issue38314

Unix read pipe is missing method available for other read transports
within the aynscio protocol, which checks that the transport read is not
paused or the transport is not closing.
@calluw
Copy link
Contributor Author

calluw commented Nov 4, 2019

@aeros Hi Kyle, does this need a news or could you add the skip news label for me? I am contributing as part of the EnHackathon team: https://enhackathon.github.io/.

@asvetlov
Copy link
Contributor

asvetlov commented Nov 4, 2019

Please avoid mocking but write a test that uses a pair of real sockets connected via loopback interface (localhost).

Mocking is highly not reliable; we have a lot of problems in asyncio behind of this.

P.S.
Yes, NEWs is required for this feature.

Copy link
Contributor

@asvetlov asvetlov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please fix my comments.
The code change itself is correct.

@bedevere-bot
Copy link

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

And if you don't make the requested changes, you will be poked with soft cushions!

@calluw
Copy link
Contributor Author

calluw commented Nov 4, 2019

Hi @asvetlov, thanks for your comments on the first draft. However, I'd like to ask for some clarification on the changes you've asked for:

  • Within this test suite, the style of tests is distinct from integration tests like opening sockets into more unit-based tests by mocking the pipe and file descriptors: should we break from this style of tests within the same test suite?
  • Also, I am not sure how is_reading() would translate in the socket opening integration test asked for when it just checks internal state: its functionality is constrained/verified by the current unit test.

If the requested changes are needed for merge, would you be able to give some guidance on making them?
This is my first contribution PR so apologies if I have misunderstood something.

@asvetlov
Copy link
Contributor

asvetlov commented Nov 4, 2019

The asyncio test suite is in the middle of translation from primarily mock-based tests to almost solely functional ones (this is our target).

Maybe a separate test case in the same file fits better to our needs. Currently, there are a lot of functional tests inside test_events.py; it makes the test file unmaintainable.

That's why unit test pipes better to sit in test_unix_events.py (or even not existing yet test_unix_pipes.py).

The test scenario could be:

  1. Create a pipe pair.
  2. Create a pipe reader (loop.connect_read_pipe())
  3. Check pipe.is_reading()
  4. Call pipe.pause_reading()
  5. Check pipe.is_reading()
  6. Call pipe.resume_reading()
  7. Check pipe.is_reading()
  8. Call pipe.close()
  9. Check pipe.is_reading()

Something like this.

…7046)

Provide Py_EnterRecursiveCall() and Py_LeaveRecursiveCall() as
regular functions for the limited API. Previously, there were defined
as macros, but these macros didn't work with the limited API which
cannot access PyThreadState.recursion_depth field.

Remove _Py_CheckRecursionLimit from the stable ABI.

Add Include/cpython/ceval.h header file.
@aeros
Copy link
Contributor

aeros commented Nov 4, 2019

@CallumQuick

Hi Kyle, does this need a news or could you add the skip news label for me?

I think this one could benefit from a brief news entry since it's implementing a new public method (even if the new method is fairly simple and within a private class). I'll add an asyncio label though.

calluw and others added 9 commits November 4, 2019 20:40
Co-Authored-By: Kyle Stanley <aeros167@gmail.com>
* Add _Py_EnterRecursiveCall() and _Py_LeaveRecursiveCall() which
  require a tstate argument.
* Pass tstate to _Py_MakeRecCheck() and  _Py_CheckRecursiveCall().
* Convert Py_EnterRecursiveCall() and Py_LeaveRecursiveCall() macros
  to static inline functions.

_PyThreadState_GET() is the most efficient way to get the tstate, and
so using it with _Py_EnterRecursiveCall() and
_Py_LeaveRecursiveCall() should be a little bit more efficient than
using Py_EnterRecursiveCall() and Py_LeaveRecursiveCall() which use
the "slower" PyThreadState_GET().
* Add tstate parameter to _Py_CheckFunctionResult()
* Add _PyErr_FormatFromCauseTstate()
* Replace PyErr_XXX(...) with _PyErr_XXX(state, ...)
Remove UNUSED macro: use Py_UNUSED() macro instead.
Fixed what seemed to be a weird phrasing.
After python#9665, this moves the remaining types in posixmodule to be heap-allocated to make it compatible with PEP384 as well as modifying all the type accessors to fully make the type opaque.

The original PR that got messed up a rebase: python#10854. All the issues in that commit have now been addressed since python#11661 got committed.

This change also removes any state from the data segment and onto the module state itself.


https://bugs.python.org/issue35381



Automerge-Triggered-By: @encukou
Additional note: the `method_check_args` function in `Objects/descrobject.c` is written in such a way that it applies to all kinds of descriptors. In particular, a future re-implementation of `wrapper_descriptor` could use that code.

CC @vstinner @encukou 


https://bugs.python.org/issue37645



Automerge-Triggered-By: @encukou
@calluw
Copy link
Contributor Author

calluw commented Nov 12, 2019

Thanks for the writeup @asvetlov.
I will take a look at writing a functional test for this change today (and start a new "test case" for Unix read transport functional tests generally).

Callum added 3 commits November 12, 2019 10:34
Unix read pipe is missing method available for other read transports
within the aynscio protocol, which checks that the transport read is not
paused or the transport is not closing.
@calluw calluw requested review from methane, rhettinger, tiran, vsajip and a team as code owners November 12, 2019 16:21
@calluw
Copy link
Contributor Author

calluw commented Nov 12, 2019

Hi @asvetlov, I have made the requested changes; please review again.

I added a new file Lib/test/test_asyncio/test_unix_pipe.py which defines a new functional test suite for Unix read transport pipes. The test suite sets up two file handles with a read pipe transport registered on the event loop.

Added a test to the suite for verifying the new behaviour of is_reading() for _UnixReadPipeTransport.

Thanks,
Callum

@bedevere-bot
Copy link

Thanks for making the requested changes!

@asvetlov: please review the changes made to this pull request.

@calluw
Copy link
Contributor Author

calluw commented Nov 21, 2019

@asvetlov, please could you look at the changes requested?

@calluw
Copy link
Contributor Author

calluw commented Dec 11, 2019

@asvetlov, please could you take a look at these updates? Thanks

@zware
Copy link
Member

zware commented Dec 11, 2019

@CallumQuick, after a quick look at the changes here, I think this could do with a clean rebase on master in a new PR (I would suggest just force-pushing over this, but apparently GitHub behaves weirdly with force-push in some situations).

@calluw
Copy link
Contributor Author

calluw commented Dec 30, 2019

@asvetlov, @zware: New PR with updated summary at #17755.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.