Skip to content
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

Addresses #1958: Move code that handles job into its own method #1964

Merged
merged 3 commits into from
Apr 18, 2021
Merged

Addresses #1958: Move code that handles job into its own method #1964

merged 3 commits into from
Apr 18, 2021

Conversation

cslecrone
Copy link
Contributor

Attempting to address #1958 by moving the code that handles jobs into its own method. This is my first contribution, so let me know if I need to do anything differently. Thanks!

@codecov
Copy link

codecov bot commented Apr 16, 2021

Codecov Report

Merging #1964 (b1d558b) into master (dc0e9bc) will increase coverage by 0.04%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #1964      +/-   ##
==========================================
+ Coverage   99.58%   99.63%   +0.04%     
==========================================
  Files         114      114              
  Lines       14627    14627              
  Branches     1119     1119              
==========================================
+ Hits        14567    14574       +7     
+ Misses         43       37       -6     
+ Partials       17       16       -1     
Impacted Files Coverage Δ
trio/_core/_thread_cache.py 100.00% <100.00%> (ø)
trio/testing/_check_streams.py 99.33% <0.00%> (+0.66%) ⬆️
trio/tests/test_socket.py 100.00% <0.00%> (+0.81%) ⬆️

@njsmith
Copy link
Member

njsmith commented Apr 16, 2021

That's weird... it looks like Travis just... doesn't know about this PR, for some reason: https://travis-ci.com/github/python-trio/trio/pull_requests

Might be related to their limited OSS credits, but OTOH they are currently building the latest commit to the master branch, so... idk. We should get off of Travis (see #1785). For right now, I'll try closing/reopening and see if that's enough to tickle Travis into doing something.

@njsmith njsmith closed this Apr 16, 2021
@njsmith njsmith reopened this Apr 16, 2021
@njsmith
Copy link
Member

njsmith commented Apr 16, 2021

Looks like travis is running now, so fingers crossed it works out 🤞

Anyway, the code change looks good! Could you add a comment explaining why _handle_job is separated into its own method?

@cslecrone
Copy link
Contributor Author

Of course! Added one just now.

@richardsheridan
Copy link
Contributor

In #1864 (comment) @oremanj expressed concerns about injecting extra function frames into frequently-called codepaths, preferring del everywhere in that case. I wonder if he would raise the some objection here given the opportunity? He ran into the same issue while implementing #1652 (https://github.com/python-trio/trio/pull/1652/files#r486806508) and bugfixed it by using del result, @njsmith noted in #1958.

@njsmith
Copy link
Member

njsmith commented Apr 17, 2021

In #1864 (comment) @oremanj expressed concerns about injecting extra function frames into frequently-called codepaths, preferring del everywhere in that case. I wonder if he would raise the some objection here given the opportunity?

Ah, interesting point, I didn't think of that! Thanks for making the connection.

Looking at it, I think this case is different: there he was talking about the core scheduling loop, which runs on every checkpoint, so it's like... the hottest code in trio by a long way. Here, we're talking about one extra frame per job assigned to a worker thread. Passing a job into a worker thread is pretty cheap, but it's still much much more expensive than pushing a call frame. Concretely, the measurements in #1545 are in tens of µs, while on my same laptop a trivial Python function call is in tens of ns, so ~3 orders of magnitude faster. So in this case I don't think it's a concern.

@oremanj
Copy link
Member

oremanj commented Apr 18, 2021

I’m not worried about the overhead in this case, though I agree it’s good to think about in general!

@njsmith njsmith merged commit cb06242 into python-trio:master Apr 18, 2021
@trio-bot
Copy link

trio-bot bot commented Apr 18, 2021

Hey @cslecrone, it looks like that was the first time we merged one of your PRs! Thanks so much! 🎉 🎂

If you want to keep contributing, we'd love to have you. So, I just sent you an invitation to join the python-trio organization on Github! If you accept, then here's what will happen:

  • Github will automatically subscribe you to notifications on all our repositories. (But you can unsubscribe again if you don't want the spam.)

  • You'll be able to help us manage issues (add labels, close them, etc.)

  • You'll be able to review and merge other people's pull requests

  • You'll get a [member] badge next to your name when participating in the Trio repos, and you'll have the option of adding your name to our member's page and putting our icon on your Github profile (details)

If you want to read more, here's the relevant section in our contributing guide.

Alternatively, you're free to decline or ignore the invitation. You'll still be able to contribute as much or as little as you like, and I won't hassle you about joining again. But if you ever change your mind, just let us know and we'll send another invitation. We'd love to have you, but more importantly we want you to do whatever's best for you.

If you have any questions, well... I am just a humble Python script, so I probably can't help. But please do post a comment here, or in our chat, or on our forum, whatever's easiest, and someone will help you out!

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

Successfully merging this pull request may close these issues.

4 participants