Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add blocking and timeout params to Pool.add #1032
This PR adds a
This allows clients of
I like the idea! Thanks for your work on this. While it's not directly applicable to the servers that come with gevent (by the time they're ready to spawn, it's really too late to quit without losing a request, and there's no out-of-band defined mechanisms to communicate with clients that situation---well, there are some HTTP response codes in that special case, but usually a reverse proxy is better at managing that sort of stuff), but I can see it being useful in other areas.
I left some review comments. This will also need tests added to src/greentest/test__pool.py and an entry in CHANGES.rst. If you'd like, I can tackle these items (so long as the checkbox to allow maintainers to access the PR was checked.)
Looking better! There's one test failure to address (see comments) and the decisions around the exception.
Vaguely related, it occurs to me that it would be nice for
Pool.spawn to be able to pass these parameters down (
Pool.add) but given the existing API that's non-trivial and better left for later.
Yep, I had the same thought--in fact that's exactly the way I originally wanted to use this from my own code.
But yes, the API for
Thanks for making those changes. There's a test failure and an exception handling issue to address. If you rebase on master, the builds on Travis should go green.
Hmm, when I was reviewing exceptions, the example that I had to write made me have second thoughts about this. Here's that example:
def do_something(blocking, timeout): greenlet = gevent.spawn(...) try: pool.add(greenlet, blocking, timeout) except PoolFull: # pool was full greenlet.kill()
The problem I see is that this API invites a race condition. Unless the caller is very careful to not start the greenlet before calling
Now, that race condition already exists if you call
I think two things need to happen:
Both of those things can happen after this PR, I'm only writing it here because this is when I noticed it.
Agreed that the ideal interface would be to add
Nevertheless, I'd love to find a way to solve this, not only to avoid the potential race condition you pointed out, but also because my own particular use case would be made easier (my code already uses
I'm ambivalent about this proposal, but: what if we added two "reserved" kwargs to
The likelihood that some existing code is passing an arg named
Nope, I meant start
I gave that some consideration, but I'm currently thinking that if someone needs