Rename run_sync_in_worker_thread -> run_sync_in_thread

See python-triogh-810

Author: njsmith

docs/source/history.rst

@@ -560,7 +560,7 @@ Upcoming breaking changes with warnings (i.e., stuff that in 0.2.0
   functions that take and run a synchronous function. As part of this:
 
   * ``run_in_worker_thread`` is becoming
-    :func:`run_sync_in_worker_thread`
+    ``run_sync_in_worker_thread``
 
   * We took the opportunity to refactor ``run_in_trio_thread`` and
     ``await_in_trio_thread`` into the new class
@@ -655,7 +655,7 @@ CPython, or PyPy3 5.9+.
 Other changes
 ~~~~~~~~~~~~~
 
-* :func:`run_sync_in_worker_thread` now has a :ref:`robust mechanism
+* :func:`run_sync_in_thread` now has a :ref:`robust mechanism
   for applying capacity limits to the number of concurrent threads
   <worker-thread-limiting>` (`#10
   <https://github.com/python-trio/trio/issues/170>`__, `#57

docs/source/reference-core.rst

@@ -1566,7 +1566,7 @@ In acknowledgment of this reality, Trio provides two useful utilities
 for working with real, operating-system level,
 :mod:`threading`\-module-style threads. First, if you're in Trio but
 need to push some blocking I/O into a thread, there's
-:func:`run_sync_in_worker_thread`. And if you're in a thread and need
+:func:`run_sync_in_thread`. And if you're in a thread and need
 to communicate back with Trio, you can use a
 :class:`BlockingTrioPortal`.
 
@@ -1589,7 +1589,7 @@ are spawned and the system gets overloaded and crashes. Instead, the N
 threads start executing the first N jobs, while the other
 (100,000 - N) jobs sit in a queue and wait their turn. Which is
 generally what you want, and this is how
-:func:`trio.run_sync_in_worker_thread` works by default.
+:func:`trio.run_sync_in_thread` works by default.
 
 The downside of this kind of thread pool is that sometimes, you need
 more sophisticated logic for controlling how many threads are run at
@@ -1636,10 +1636,10 @@ re-using threads, but has no admission control policy: if you give it
 responsible for providing the policy to make sure that this doesn't
 happen – but since it *only* has to worry about policy, it can be much
 simpler. In fact, all there is to it is the ``limiter=`` argument
-passed to :func:`run_sync_in_worker_thread`. This defaults to a global
+passed to :func:`run_sync_in_thread`. This defaults to a global
 :class:`CapacityLimiter` object, which gives us the classic fixed-size
 thread pool behavior. (See
-:func:`current_default_worker_thread_limiter`.) But if you want to use
+:func:`current_default_thread_limiter`.) But if you want to use
 "separate pools" for type A jobs and type B jobs, then it's just a
 matter of creating two separate :class:`CapacityLimiter` objects and
 passing them in when running these jobs. Or here's an example of
@@ -1679,7 +1679,7 @@ time::
            return USER_LIMITERS[user_id]
        except KeyError:
            per_user_limiter = trio.CapacityLimiter(MAX_THREADS_PER_USER)
-           global_limiter = trio.current_default_worker_thread_limiter()
+           global_limiter = trio.current_default_thread_limiter()
            # IMPORTANT: acquire the per_user_limiter before the global_limiter.
            # If we get 100 jobs for a user at the same time, we want
            # to only allow 3 of them at a time to even compete for the
@@ -1690,17 +1690,17 @@ time::
 
 
    async def run_in_worker_thread_for_user(user_id, async_fn, *args, **kwargs):
-       # *args belong to async_fn; **kwargs belong to run_sync_in_worker_thread
+       # *args belong to async_fn; **kwargs belong to run_sync_in_thread
        kwargs["limiter"] = get_user_limiter(user_id)
-       return await trio.run_sync_in_worker_thread(asycn_fn, *args, **kwargs)
+       return await trio.run_sync_in_thread(asycn_fn, *args, **kwargs)
 
 
 Putting blocking I/O into worker threads
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-.. autofunction:: run_sync_in_worker_thread
+.. autofunction:: run_sync_in_thread
 
-.. autofunction:: current_default_worker_thread_limiter
+.. autofunction:: current_default_thread_limiter
 
 
 Getting back into the Trio thread from another thread

docs/source/reference-core/blocking-trio-portal-example.py

@@ -22,7 +22,7 @@ async def main():
         # In a background thread, run:
         #   thread_fn(portal, receive_from_trio, send_to_trio)
         nursery.start_soon(
-            trio.run_sync_in_worker_thread,
+            trio.run_sync_in_thread,
             thread_fn, portal, receive_from_trio, send_to_trio
         )
 

docs/source/reference-hazmat.rst

@@ -442,7 +442,7 @@ This logic is a bit convoluted, but accomplishes all of the following:
   loop outside of the ``except BlockingIOError:`` block.
 
 These functions can also be useful in other situations. For example,
-when :func:`trio.run_sync_in_worker_thread` schedules some work to run
+when :func:`trio.run_sync_in_thread` schedules some work to run
 in a worker thread, it blocks until the work is finished (so it's a
 schedule point), but by default it doesn't allow cancellation. So to
 make sure that the call always acts as a checkpoint, it calls

docs/source/reference-io.rst

@@ -479,7 +479,7 @@ To understand why, you need to know two things.
 First, right now no mainstream operating system offers a generic,
 reliable, native API for async file or filesystem operations, so we
 have to fake it by using threads (specifically,
-:func:`run_sync_in_worker_thread`). This is cheap but isn't free: on a
+:func:`run_sync_in_thread`). This is cheap but isn't free: on a
 typical PC, dispatching to a worker thread adds something like ~100 µs
 of overhead to each operation. ("µs" is pronounced "microseconds", and
 there are 1,000,000 µs in a second. Note that all the numbers here are

newsfragments/810.removal.rst

@@ -0,0 +1,5 @@
+``run_sync_in_worker_thread`` was too much of a mouthful – now it's
+just called `run_sync_in_thread` (though the old name still works with
+a deprecation warning, for now). Similarly,
+``current_default_worker_thread_limiter`` is becoming
+`current_default_thread_limiter`.

notes-to-self/blocking-read-hack.py

@@ -29,7 +29,7 @@ async def kill_it_after_timeout(new_fd):
         async with trio.open_nursery() as nursery:
             nursery.start_soon(kill_it_after_timeout, new_fd)
             try:
-                data = await trio.run_sync_in_worker_thread(os.read, new_fd, count)
+                data = await trio.run_sync_in_thread(os.read, new_fd, count)
             except OSError as exc:
                 if cancel_requested and exc.errno == errno.ENOTCONN:
                     # Call was successfully cancelled. In a real version we'd

notes-to-self/thread-dispatch-bench.py

@@ -2,7 +2,7 @@
 # minimal a fashion as possible.
 #
 # This is useful to get a sense of the *lower-bound* cost of
-# run_sync_in_worker_thread
+# run_sync_in_thread
 
 import threading
 from queue import Queue

trio/__init__.py

@@ -32,7 +32,7 @@
 )
 
 from ._threads import (
-    run_sync_in_worker_thread, current_default_worker_thread_limiter,
+    run_sync_in_thread, current_default_thread_limiter,
     BlockingTrioPortal
 )
 
@@ -100,6 +100,20 @@
                 "library 'subprocess' module"
             ),
         ),
+    "run_sync_in_worker_thread":
+        _deprecate.DeprecatedAttribute(
+            run_sync_in_thread,
+            "0.12.0",
+            issue=810,
+            instead=run_sync_in_thread,
+        ),
+    "current_default_worker_thread_limiter":
+        _deprecate.DeprecatedAttribute(
+            current_default_thread_limiter,
+            "0.12.0",
+            issue=810,
+            instead=current_default_thread_limiter,
+        ),
 }
 
 # Having the public path in .__module__ attributes is important for:

trio/_core/_entry_queue.py

@@ -132,7 +132,7 @@ class TrioToken:
 
     1. It lets you re-enter the Trio run loop from external threads or signal
        handlers. This is the low-level primitive that
-       :func:`trio.run_sync_in_worker_thread` uses to receive results from
+       :func:`trio.run_sync_in_thread` uses to receive results from
        worker threads, that :func:`trio.open_signal_receiver` uses to receive
        notifications about signals, and so forth.