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

[cslecrone]

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]

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]

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]

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]

Of course! Added one just now.

[richardsheridan]

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]

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]

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

[trio-bot]

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!