-
-
Notifications
You must be signed in to change notification settings - Fork 24
Conversation
… loop The use-case of stacking `.run()` calls within the same event loop is not affected by this change. Fixes asyncio-3.5 test: test_base_events.RunningLoopTests.test_running_loop_within_a_loop
Hi! Sorry for the delay. First up, thanks heaps for looking into this! It's very exciting. A few questions/thoughts:
In future, if you could use smaller, more clearly separated commit messages, that would be good - I think most of this code is not necessarily Windows specific, so at the moment I'm having quite a bit of difficulty finding the changes that are directly necessary for Windows support. All of that said though, I think this is pretty awesome! I've created a new branch named I'll start working on getting some automated testing going for major Python versions we care about. I'm not sure what we can do with Windows for automated testing though, so if you have any suggestions, I'm interested in hearing them :) |
Seems most project on GitHub uses appveyor for Windows automated testing. You can get the idea from https://github.com/harvimt/quamash |
You're welcome, thanks for looking into this!
Actually the submitted code does exactly that:
I'd recommend adding in the integration tests of serious
Yes, the current code uses
I'm sad about this as well, but implementing the official interfaces (as outline above) requires one to either (a) implement your own transport implementations or (b) reuse one of the official implementations. The problem with (b) being, that both of the official implementations rely on private implementation details of their respective event loops to implement their transport functionally. (Which is a real pity because the Window Regarding licensing issues: I'm still not sure whether Regarding maintenance: It's hard to say how this will play out, but it is somewhat unlikely that any major changes to this code will be required anything soon. After all, all used APIs (event loop, sockets, public interfaces) are stable and the concept of transports itself has had some long-time testing in the As I said I'm not particularly happy about this either, but I believe it to be the lesser evil.
Could you please point me to the place in
Will do. 😿
Thanks!
I will, this was just the big "getting it off the ground" commit that contained several days of trying and rewriting things to produce something that would actually work.
Yes, but almost all of the code in
Thanks, will do! Before I can start working on adding support on UDP, UDS, Pipes, subprocesses, … we need to settle the question on how to proceed with |
Known issues: - TCP connection closings are not received with the standard GLib or GTK event loop on Windows - TLS does not work with Python 3.4 and below (even outside of Windows) - UDP and Pipe support missing - Support for the `add_reader` and `add_writer` APIs is still lacking - Unix domain sockets and signals support is also still missing - Subprocess support is untested currently Passes most of the `aiohttp` test suite on Linux (except for 2 tests that I believe are incorrect), Windows results for the test suite are not quite on par yet, but a standard HTTPS with a large number of requests and many transfered bytes completed without errors.
… limited to sockets on Windows)
…ent.SelectorEventLoop` with some funky inheritance tricks
…t would cause protocols and transports to hang for non-obvious reasons Also finally enable the standard GLib event loop instead of spinning our own in Python.
… less stringent on the clock precision of `call_at`
Ok, I'm (finally) done with the implementation now! All mentioned issues have been addressed (using the current transport approach)! Currently there is one test failure left on Unix: The That's all from me for now! 😀 Waiting for your review of the (currently) final codebase! |
Oh and I should add that I wrote this set of basic tests while hunting for bugs in the new codebase: Reference output:
Maybe that's useful for additional unit tests? |
This is awesome!! Fantastic work! Remarks/questions:
As an aside, I've got Linux-based CI for 3.4, 3.5 and 3.6 going now. I'll check out appveyor over the weekend and see how I go with that, and then I think I'll be much more comfortable merging this in :) thank you again for all this work! This is above and beyond what I expected anyone to do. |
🎉 So we're basically done? 🎉 Regarding you last couple of points:
|
I think so! These tests look useful, I'm happy to transform these into proper tests. Your trickery was quite obvious in retrospect, I should have thought of conftest! :) How have you been building and testing on Windows, by the way? It's been about ten years since I've built any software on Windows, so this is all completely unfamiliar to me. MSYS2 seems to be the suggested environment for building GTK3 packages on Windows, but it doesn't seem to be a sensible way to run Python, particularly given sys.platform is "msys". I haven't even made it to the point where PyGI is a possibility, so I'm curious as to what I'm missing :) |
I'll hereby confess that I haven't built a single Windows binary on Windows in my entire life 😸
I also found the official msys2 shell to be unbearably slow and causing issues with interactive terminal mode for some reason, so I switched to good old
(WITHOUT any extra quotes!) before continuing as if it were a Linux shell. Important clearification: Apps compiled with MinGW run as normal Windows apps on the win32-API and can be used outside of the msys2 install. In Python this means that the interpreter will report . Alternatively you can try finding a Python 3.4.x installer somewhere online and install the PyGObject for Windows suite on top. (As far as I can tell from the changelog their somewhat reluctant to break Windows XP support and supporting Python 3.5 [which doesn't support Windows XP anymore] seems to force that for some reason.) |
Gtk dropped support for Windows XP, so you don't need to worry about it. Something to be aware of is if your package contains compiled elements then you can't mix MSys and VC++ compiled python + libraries. (I don't think gbulb does). Python + Windows is not the best - a lot of people have switched to Conda which makes a lot of these things easier, but last time I looked it didn't have all the Gtk libraries that I needed. |
Sorry for the lack of communication on my part! I've been swamped with a bunch of things lately. I should have some time this weekend to finally get around to Windows testing. |
This test breakage is in test_call_soon_priority, which we talked about, so I'm happy to merge this in and then remove the bogus test. While I'm here, I finally tested things on Windows and it worked quite well! Thank you so much for this work, it's fantastic. |
@Alexander255 can you take a look at issue #24 please! |
As can be seen from the list of known issues below, this still needs some work to be really usable, but the initial implementation is done and if you have any feedback or suggestions about it I'd be happy to discuss that with you and incorporate any necessary changes.
As you study the code you'll probably notice that this is a mostly rewrite of the library, implementing a full-fledged event loop (similar to
asyncio
'sSelectorEventLoop
andProactorEventLoop
) on top ofbase_events.BaseEventLoop
instead of somehow trying to useSelectorEventLoop
for this. This IMHO makes for more readable and stable code, because we're simply implementing the well defined interfaces from theBaseEventLoop
instead of monkey-patchingSelectorEventLoop
to fit our needs.Known issues:
TCP connection closings are not received with the standard GLib or GTK event loop on WindowsTLS does not work with Python 3.4 and below (even outside of Windows)UDP and Pipe support missingSupport for theadd_reader
andadd_writer
APIs is still lackingUnix domain sockets and signals support is also still missingSubprocess support is untested currentlyNot tested with anything older than Python 3.5.2Passes most of the
aiohttp
test suite on Linux (except for 2 tests that I believe to be incorrect after debugging them for a couple of hours), Windows results for the test suite are not quite on par yet, but a standard HTTPS with a large number of requests and many transferred bytes has completed without errors.