Skip to content

Conversation

@davidszotten
Copy link
Contributor

@davidszotten davidszotten commented May 16, 2016

update

bugfix: only trampoline after catching a "blocking" ioerror. trampolining might otherwise fail, e.g. if using epoll and the fd happens to be a regular file (would never block)

test thanks to @Haypo from #257

original description, kept for posterity

wasn't able to figure out how to reproduce in a test, but can be trigged with a pytest test:

import eventlet
eventlet.monkey_patch()

pytest_plugins = "pytester"


def test_foo(testdir):

    testdir.makepyfile(
        """
        def test_foo():
            print('foo')
        """
    )
    result = testdir.runpytest()
    assert result.ret == 0

hangs on py3 without this patch

except OSError as e:
if get_errno(e) not in SOCKET_BLOCKING:
raise IOError(*e.args)
self._trampoline(self, read=True)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

this works either way, but i think having it inside the except clause is more semantically correct (and copying this is what caused the error below)

@temoto
Copy link
Member

temoto commented May 16, 2016

Thanks for patch.
How to read this test? I fail to understand what exactly does it verify.

@davidszotten
Copy link
Contributor Author

do you mean test_foo? That's distilled from a test testing a pytest plugin. Without the patch in this pr, running that test the runner just hangs. The patch stops the hanging.

Tried but failed to trigger the same issue from the eventlet test suite. Not suggesting the above should be added, just included it for reference if anyone else wants to try to to reproduce it.

@davidszotten
Copy link
Contributor Author

do you need anything else here?

@temoto
Copy link
Member

temoto commented May 20, 2016

Not with code, but field testing would be nice.

@davidszotten
Copy link
Contributor Author

is that something you are looking for from me?

@jstasiak
Copy link
Contributor

I think we should have a reliable unit test included in the same patch as the issue seems nontrivial.

@davidszotten
Copy link
Contributor Author

@jstasiak as i mentioned, i haven't been able to reproduce in a test scenario. i can trigger the bug using pytest and the minimal example in the description. any help writing a test would be appreciated

@temoto
Copy link
Member

temoto commented May 22, 2016

I take test.

Anybody willing to run this version on their systems - much appreciated.

@davidszotten
Copy link
Contributor Author

To add another datapoint: I had been testing this on os x, which is where pytest hangs without this patch. On linux i instead get a Second simultaneous read exception.

@temoto
Copy link
Member

temoto commented May 23, 2016

No offense, I'm on OSX desktop too, but it's kind of irrelevant. So new symptom is second read. Which may be related to these issues: #94 #98 #273 so watch out, we already had regressions related to this code.

@davidszotten
Copy link
Contributor Author

davidszotten commented May 23, 2016

So if i understand correctly, this change just disturbs things enough (in my particular case) to avoid a bug elsewhere. In that case, this is a simple performance improvement (no need to trampoline until we block), and the existing test should be sufficient.

@davidszotten
Copy link
Contributor Author

ok. some more digging: the simultaneous read might be a red herring (or an effect of something). hadn't noticed there was another exception being raised earlier:

>                   self.poll.register(fileno, mask)
E                   PermissionError: [Errno 1] Operation not permitted

looks like we are getting

EPERM The target file fd does not support epoll. This error occur if fd refers to, for example, a regular file or directory.

travis run:
https://travis-ci.org/mattbennett/eventlet-pytest-bug/jobs/133923901

do you know what causes this?

@davidszotten
Copy link
Contributor Author

davidszotten commented Jun 1, 2016

ok, now that i have something better to look for, i guess i'm just hitting #256, fixed by #257 (merge conflicts are just that multiple tests were added in tests/patcher_test.py). happy to rebase that branch and raise a new pr if you prefer?

could still (separately) take the slight perf improvement in this pr, though that's less important

@temoto
Copy link
Member

temoto commented Jun 2, 2016

Thanks for investigation. Let's put this trampoline optimisation on hold for a while and continue with #257.

@davidszotten
Copy link
Contributor Author

davidszotten commented Jun 2, 2016

so i'm back to thinking this is the proper fix for #256. apologies for the amount of back and forth, but i think my understanding of what's going on is slowly improving. i've incorporated the test from #257 which passes with this fix (and fails without it).

@davidszotten
Copy link
Contributor Author

hi. do you need anything else from me to move this forward?

@mattbennett
Copy link
Contributor

It would be great to see a fix for this, or #257

@@ -0,0 +1,42 @@
import eventlet
eventlet.monkey_patch()
Copy link
Member

Choose a reason for hiding this comment

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

Please, follow this pattern for isolated tests:

__test__ = False

if __name__ == '__main__':
    import eventlet
    # and everything else

monkey_patch() at module level is a hidden bomb in a file that is potentially imported by test runner collector.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

thanks, hadn't noticed that the standards had moved since that test was written. updated now

@temoto temoto added this to the v0.20 milestone Jul 1, 2016
@temoto temoto merged commit 863a1b7 into eventlet:master Jul 1, 2016
@temoto
Copy link
Member

temoto commented Jul 1, 2016

Field testing is very welcome.

Thanks, @davidszotten

@davidszotten
Copy link
Contributor Author

thanks. nameko is a decent sized open source library that makes heavy use of eventlet. there is already a travis job that runs against the latest released version of eventlet, but if it would help we could probably add one against eventlet master (with failure allowed)

@temoto
Copy link
Member

temoto commented Jul 1, 2016

Yes, please! CI of different code against master would be super awesome.

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.

4 participants