Hi, [if this is not the right forum to post patches for tulip, please redirect me to the correct one. There doesn't appear to be a mailing list for tulip at the moment. And this list is where most/all of the discussion is taking place.] Please find attached 4 patches: 0001-run-fd-callbacks.patch This patch will run callbacks for readers and writers in the same loop iteration as when the fd got ready. Copying from my previous email, this is to support the following idiom: # handle_read() sets the "ready" flag loop.add_reader(fd, handle_read) while not ready: loop.run_once() The patch currently dispatches callbacks twice in each iteration, once before blocking and once after. I tried to dispatch only once after blocking, but this made the SSL transport test hang. The reason is that the create_transport task is scheduled with call_soon(), and only when the task first runs, a file descriptor is added. So unless you dispatch before blocking, this task will never get started. 0002-call-every-iteration.patch This adds a call_every_iteration() method to the event loop. This callback runs *before* blocking. 0003-fix-typo.patch 0004-remove-wrong-comments.patch Two trivial patches. Regards, Geert
On Fri, Dec 21, 2012 at 6:31 AM, Geert Jansen <geertj@gmail.com> wrote:
This is a fine place, but you would make my life even easier by uploading the patches to codereview.appspot.com, so I can review them and send comments in-line. I've given you checkin permissions. Please send a contributor form to the PSF (http://www.python.org/psf/contrib/contrib-form/).
Interesting. Go ahead and submit.
There's one odd thing here: you remove cancelled everytime handlers *after* already scheduling them. It would seem to make more sense to schedule them first. Also, a faster way to do this would be self._everytime = [handler in self._everytime if not handler.cancelled] (Even if you iterate from the back, remove() is still O(N), so if half the handlers are to be removed, your original code would be O(N**2).)
Go ahead! PS. If you want to set up a mailing list or other cleverness I can set you up as a project admin. (I currently have all patches mailed to me but we may want to set up a separate list for that.) -- --Guido van Rossum (python.org/~guido)
On Fri, Dec 21, 2012 at 7:57 AM, Guido van Rossum <guido@python.org> wrote:
Whoa! I just figured out the problem. You don't have to run the ready queue twice. You just have to set the poll timeout to 0 if there's anything in the ready queue. Please send me an updated patch before submitting. -- --Guido van Rossum (python.org/~guido)
Hi! I've been working in some tests to the pollers (Kqueue, Epoll ..) that may interest you guys.. My goal is to create test cases for each poller situation (ie: how to detect client disconnection with epoll and unix pipes? or tcp sockets..) and understand how all those pollers are different from each other and how we can map a generic events with all those possible underlying implementations. I already did some Epoll and Kqueue tests here: https://bitbucket.org/felipecruz/tulip/commits best regards, Felipe Cruz 2012/12/21 Guido van Rossum <guido@python.org>
On Fri, Dec 21, 2012 at 10:09 AM, Felipe Cruz <felipecruz@loogica.net> wrote:
That goal sounds great.
I already did some Epoll and Kqueue tests here: https://bitbucket.org/felipecruz/tulip/commits
Hm... Your clone is behind, a lot has changed since you made those commits. You may have to merge from the main repo. Specific comments: - I prefer to use my existing test infrastructure rather than 3rd party tools; dependencies in this early stage make it too hard for people to experiment. (It's okay to add a rule to the Makefile to invoke your favorite test discovery tool; but it's not okay to add imports to the Python code that depends on a 3rd party test framework.) - Your code to add flags or eventmask to the events list seems incomplete -- the UnixEventLoop doesn't expect poll() to return a tuple so all my own tests break... -- --Guido van Rossum (python.org/~guido)
On Fri, Dec 21, 2012 at 4:57 PM, Guido van Rossum <guido@python.org> wrote:
I tried to get Tulip added as a new repository there, but i'm probably doing something wrong.. In the mean time i'm sending my updated patches below..
I've given you checkin permissions. Please send a contributor form to the PSF (http://www.python.org/psf/contrib/contrib-form/).
Done!
New patch attached.
ACK regarding the comment on O(N^2). The reason i implemented it like this is that i didn't want to regenerate the list at every iteration of the loop (maybe i'm unduly worried though...). The attached patch does as you suggest but only in case there are cancelled handlers.
I'm happy to be an admin and set up a Google Groups for this. On the other hand, tulip is supposed to become part of the standard library, right? Maybe python-dev is as a good place to discuss tulip? Your call.. I'll go ahead and commit the two trivial patches, and wait for your ACK on the updated versions of the other two. Regards, Geert
On Fri, Dec 21, 2012 at 1:59 PM, Geert Jansen <geertj@gmail.com> wrote:
Yeah, sorry, the upload form is not to be used. You should use the upload.py utility instead: https://codereview.appspot.com/static/upload.py
Looks good to me. Check it in!
LG, except: - Maybe rename 'cancelled' to 'any_cancelled'. - PEP 8 conformance: [foo bar], not [ foo bar ]. You can check it in after fixing those issues.
Made you an admin. Go ahead.
I think it's too soon to flood python-dev with every little detail (though I just did post there about the PEP).
I'll go ahead and commit the two trivial patches, and wait for your ACK on the updated versions of the other two.
Thanks! -- --Guido van Rossum (python.org/~guido)
On Fri, Dec 21, 2012 at 6:31 AM, Geert Jansen <geertj@gmail.com> wrote:
This is a fine place, but you would make my life even easier by uploading the patches to codereview.appspot.com, so I can review them and send comments in-line. I've given you checkin permissions. Please send a contributor form to the PSF (http://www.python.org/psf/contrib/contrib-form/).
Interesting. Go ahead and submit.
There's one odd thing here: you remove cancelled everytime handlers *after* already scheduling them. It would seem to make more sense to schedule them first. Also, a faster way to do this would be self._everytime = [handler in self._everytime if not handler.cancelled] (Even if you iterate from the back, remove() is still O(N), so if half the handlers are to be removed, your original code would be O(N**2).)
Go ahead! PS. If you want to set up a mailing list or other cleverness I can set you up as a project admin. (I currently have all patches mailed to me but we may want to set up a separate list for that.) -- --Guido van Rossum (python.org/~guido)
On Fri, Dec 21, 2012 at 7:57 AM, Guido van Rossum <guido@python.org> wrote:
Whoa! I just figured out the problem. You don't have to run the ready queue twice. You just have to set the poll timeout to 0 if there's anything in the ready queue. Please send me an updated patch before submitting. -- --Guido van Rossum (python.org/~guido)
Hi! I've been working in some tests to the pollers (Kqueue, Epoll ..) that may interest you guys.. My goal is to create test cases for each poller situation (ie: how to detect client disconnection with epoll and unix pipes? or tcp sockets..) and understand how all those pollers are different from each other and how we can map a generic events with all those possible underlying implementations. I already did some Epoll and Kqueue tests here: https://bitbucket.org/felipecruz/tulip/commits best regards, Felipe Cruz 2012/12/21 Guido van Rossum <guido@python.org>
On Fri, Dec 21, 2012 at 10:09 AM, Felipe Cruz <felipecruz@loogica.net> wrote:
That goal sounds great.
I already did some Epoll and Kqueue tests here: https://bitbucket.org/felipecruz/tulip/commits
Hm... Your clone is behind, a lot has changed since you made those commits. You may have to merge from the main repo. Specific comments: - I prefer to use my existing test infrastructure rather than 3rd party tools; dependencies in this early stage make it too hard for people to experiment. (It's okay to add a rule to the Makefile to invoke your favorite test discovery tool; but it's not okay to add imports to the Python code that depends on a 3rd party test framework.) - Your code to add flags or eventmask to the events list seems incomplete -- the UnixEventLoop doesn't expect poll() to return a tuple so all my own tests break... -- --Guido van Rossum (python.org/~guido)
On Fri, Dec 21, 2012 at 4:57 PM, Guido van Rossum <guido@python.org> wrote:
I tried to get Tulip added as a new repository there, but i'm probably doing something wrong.. In the mean time i'm sending my updated patches below..
I've given you checkin permissions. Please send a contributor form to the PSF (http://www.python.org/psf/contrib/contrib-form/).
Done!
New patch attached.
ACK regarding the comment on O(N^2). The reason i implemented it like this is that i didn't want to regenerate the list at every iteration of the loop (maybe i'm unduly worried though...). The attached patch does as you suggest but only in case there are cancelled handlers.
I'm happy to be an admin and set up a Google Groups for this. On the other hand, tulip is supposed to become part of the standard library, right? Maybe python-dev is as a good place to discuss tulip? Your call.. I'll go ahead and commit the two trivial patches, and wait for your ACK on the updated versions of the other two. Regards, Geert
On Fri, Dec 21, 2012 at 1:59 PM, Geert Jansen <geertj@gmail.com> wrote:
Yeah, sorry, the upload form is not to be used. You should use the upload.py utility instead: https://codereview.appspot.com/static/upload.py
Looks good to me. Check it in!
LG, except: - Maybe rename 'cancelled' to 'any_cancelled'. - PEP 8 conformance: [foo bar], not [ foo bar ]. You can check it in after fixing those issues.
Made you an admin. Go ahead.
I think it's too soon to flood python-dev with every little detail (though I just did post there about the PEP).
I'll go ahead and commit the two trivial patches, and wait for your ACK on the updated versions of the other two.
Thanks! -- --Guido van Rossum (python.org/~guido)
participants (3)
-
Felipe Cruz -
Geert Jansen -
Guido van Rossum