Fable review of profile child process

[Erotemic]

@TTsangSC I had Fable perform an audit of the PR and the entire repo more generally. It wrote out a plan, but did the implementation for the trickiest parts itself.

There is also a new .llm_resource_tally which is a tool I'm working on to quantify and estimate the token and ultimately environmental costs of using agentic coding.

I still have to review this all, but I'm putting it on your radar. The main document relevant to your PR is: dev/planning/fable-review-pr431-2026-07-05.md and dev/planning/fable-plan-pr431-2026-07-05.md

[TTsangSC]

(Oh crud, I accidentally last-paged when in the middle of typing something here. Gotta do it all the dang way again...)

Thanks for the input; several things:

General

• Just out of curiosity: I noticed that Fable¹ seems to be comparing between the current and previous iterations of the PR. Does it mean it had to crunch through the entire commit history of the branch?
• In .llm_resource_tally/tool/version.py you've implied that the entire vendored-in copy of llm_resource_tally is supposed to be committed into the repo anyway,² but I wonder if it makes sense to just keep the ledger and lifetime-totals.json and .gitignore the rest? Since at some point user intervention is needed to opt in and set up the commit hooks anyways – albeit with a mere python <path-to-llm_...> install – maybe the downloading and installation of llm_resource_tally could've been left inside a dev/ script?

Fable full-repo review

• F-1:
  • So we're moving to more thread-shared states... guess that is fine since we already don't have no-GIL guarantees.
  • That probably means _threading_patches.py will be unnecessary because the entire rationale of that module is to sync the .enable_count of the profiler between the spawning and the spawned threads.
  • Same goes for _test_child_procs_utils.py::_cleanup_profiling_in_current_thread() which is only a hack for cleaning up profilers created in other threads.
• F-5:
  So basically autoprofile cannot handle multiple imports on the same line pyutils/line_profiler#433. Mind giving FIX: handling multi-target (from-)import statements pyutils/line_profiler#434 a look?
• F-6:
  Not sure if I agree with the analysis here.
  1. Normalizing to the coarsest .unit ensures that we don't over-report on precision.
  2. Because .unit is directly proportional to the normalizing factors, sorting on .unit helps with preserving numerical stability.
  3. The normalized timing figures are floats, are accumulated as such, and are only converted to ints at the very end of LineStats._get_aggregated_timings(). So the assertion that the normalizing scheme "does the opposite" to minimizing errors is unfounded, at least if we want to stick to (1).
• F-11:
  I wonder if we can just take a page from the PR (runpy_patches.py::create_runpy_wrapper()), and create a patched copy of inspect with _CythonBlockFinder to be used in line_profiler.py.

Fable PR review

• P1:
  Good catch, should've written a test case for that.
• P2:
  • Yikes, wasn't aware of BaseContext.set_executable(). In that case tagging the communicated tuple and falling back to the vanilla behavior do seem ideal.
  • It may be worth looking at something like coverage.multiproc.Stowaway, which results in the .pth hook being executed when the child process unpickles the input, instead of at interpreter startup via the .pth file. I originally had that in the code, but eventually decided to trim that away since the setup "must have" already happened via .pth anyway. Seems that there might be cases where that isn't the case...
• P3:
  • Ah nice, was wondering if sysconfig works for non-venv installs.
  • The non-installation caveat may require some hacky solution for cases where _line_profiler_hooks.py isn't import-able, since the .pth always have to be a one-liner beginning with import. Maybe something like

    import importlib.util as iu; spec.loader.exec_module(mod) if (mod := (iu.module_from_spec(spec) if (spec := iu.find_spec('_line_profiler_hooks')) else None)) else None; getattr(mod, 'load_pth_hook', lambda ppid: None)(PPID)

• P7:
  Yeah the plan was to get the code there and the components stable first because actually documenting them. But it makes sense to have that in the roadmap.
• P8:
  I basically just wrote the entry-point (plugin) system to sidestep having (potetntially circular) imports; exposing the entry point is more of a side effect. Guess that it does make sense, incurs less overhead, and is more explicit to just suck that up and shove the imports into the body of the instantiatior... and we can just get rid of the entry-point stuff entirely.
• P10:
  The doubled-up warning is intentional because Logger.warning() messages may be suppressed depending on the kernprof [--verbose|--quiet [...]] setting. (See line_profiler/_logger.py::Logger.configure() and kernprof.py::_parse_arguments().)
• P11:
  • As noted in the previous discussion (and evident from the long and arduous strugglewith SIGTERM), I'm not sure if there's a way to ensure result correctness without a per-task stats dump.
  • Maybe pickling the stats and pushing it back to the parent (like what we already do for PIDs) would reduce the per-task overhead compared to writing the stats to disk.
• P13:
  I doubt if instantiating a new profiler instance tempers with tool registration, since that is only done in line_profiler/_line_profiler.pyx::_SysMonitoringState.register(), which is only invoked if the profiler is enabled. But yeah it's probably unnecessary, and if we're updating the Cython code anyway we might as well expose a Python-level hook to timers.c::hpTimerUnit().
• D.2, D.3:
  Good catch.
• D.6:
  os.environ cleanup is tested in test_child_procs.py::test_cache_dump_load(), but I guess that point the model is making is that it isn't tested to be guaranteed "in prod" because of e.g. the failing edge cases of kernprof.py::_manage_profiler.
• D.10:
  • Yeah Params.__mul__() is functionally equivalent to stacking @pytest.mark.parametrize decorators, but the point is to enable Params.__add__() which takes the default for the unlisted parameters and adds to them the listed ones. But one can maybe argue that instead of (ab-)using parametrizations it'd be clearer to split the cases into separate test functions.
  • The problems with pytest.warns are that:
    • Each such context manager can only check for a single warning specification.
    • It doesn't allow for checking against warnings. One can maybe use warnings.check_warnings() and warnings.simplefilter('error', ...) for that, but then the warnings are raised at the point of issuing, instead of being checked post-hoc and resulting in a ResultMismatch which documents what is wrong in the error message. (But then course one can also argue that the former behavior is more direct and thus better.)
• D.11:
  Yeah that one's weird. For some unholy reasons the test works with pytest --doctest-modules but not pytest --xdoctest... even more curiously, both python -m doctest and python -m xdoctest works when said file is put on the path via ${PYTHONPATH}. So I assume that to be because of maybe differing handling of the sys.path injected by pytest between the two doctest backends. I did try for quite a while to debug that before settling with the SKIP, intending to write a PR to xdoctest if needs be, but failed to locate the cause before giving up.

Footnotes

1. Hold up, am I even supposed to be looking at this at all? My being a non-American citizen and all... /jk ↩

2. This also resulted in a somewhat awkward situation where Erotemic/llm_resource_tally contains two copies of the source code. ↩

[Erotemic]

Oh crud, I accidentally last-paged when in the middle of typing something here. Gotta do it all the dang way again

That's why I type almost everything out in vim first :)

comparing between the current and previous iterations of the PR.

I gave it the context of the PR conversation. But I had your latest branch checked out when I ran the prompt. It could have read the entire history, but that wasn't my intent.

entire vendored-in copy of llm_resource_tally

Yeah, I'm reconsidering that choice. It seems like its easy enough for it to install itself .gitignored, technically its only installing a "minimal" version of itself, which doesn't include all the carbon modeling, but after looking at this PR it hit me how much bloat it was. Of course, after you commit it once, it never shows up in the diff again, and having a note in AGENTS.md and the code available means its more likely that if anyone uses an LLM to make a contribution, the resources get tracked.

F-5: Mind giving FIX: handling multi-target (from-)import statements pyutils#434 a look?

I'll make some time for it. I wanted to land this first. Preference on order?

F-6: Not sure if I agree with the analysis here.

I mean technically its right, in that you are losing the details, but it may just be overreading the intent of the doc. I agree it's a non-issue.

F-11: create a patched copy of inspect with _CythonBlockFinder to be used in line_profiler.py.

A bit more maintainer burden, but I'm not opposed to it.

P11

The remediation is just "| PR431-11 | Document (and later maybe throttle) per-task flush cost | small | — | todo |"?

Probably a good idea to document, but would throttling help in the sense that
the results would still be correct? Or would a throttle drop measurements? I
guess the more important question is how big do the stats get? And did we have
to effectively have to pay this cost before this patch for the main thread? So
now its just multipled by the number of workers? If so that seems acceptable,
but if this is a new cost that would degrade performance of existing users on
their main thread profiles when they have multiprocessing happening, then we
may need to think about this some more.

This reminds me I need to start branchmarking this tool more rigorously and
tracking regressions. If we had that it would be pretty easy to get a feel for
what the real cost of this is.

PR431-11

unholy reasons the test works with pytest --doctest-modules but not pytest --xdoctest... even more curiously, both python -m doctest and python -m xdoctest works when said file is put on the path via ${PYTHONPATH}.

The pytest integration in xdoctest is extremely old at this point. In part for backwards compatability, but also in part because it still works. I wonder if it would help if I modernized it. I could try to look into that.

Hold up, am I even supposed to be looking at this at all? My being a non-American citizen and all... /jk

Don't get me started ;)

This also resulted in a somewhat awkward situation where Erotemic/llm_resource_tally contains two copies of the source code.

100% intentional. There's a lot in the design I'm still questioning / considering, but I'm convinced that the self-replicating install is the right move for the tool.

[TTsangSC]

Replies

type almost everything out in vim first

Yeah lesson learned, that's what I ended up doing for the rewritten reply.

I wanted to land this first. Preference on order?

Personally I'd say it may be a good idea to merge small and easy fixes for correctness first, but of course if one was to always do that big features would never land. In that case I trust your judgment.

would throttling help in the sense that the results would still be correct

Um... can you clarify what you meant by throttling? Like, only writing stats every n tasks or something? (Probably not, since a per-task hook to do whatever is the only way to ensure that things get done in workers before control is passed back to the parent, which may axe it at any point.)

I've also realized that it's probably strictly easier and more performant to just go with sending the stats alongside result since we have to pickle the LineStats either way.

But yes of course it makes sense to start with documenting the overhead in any case.

did we have to effectively have to pay this cost before this patch for the main thread

In the main process stats there're no tasks to speak of and writing only happens at the end, so probably no both pre and post this this PR.

if this is a new cost that would degrade performance of existing users on their main thread profiles when they have multiprocessing happening

The changes made by the PR is entirely opt-in via --prof-child-procs, and none of patching stuff happens unless said flag/config option is set (default false; see line_profiler/rc/line_profiler.toml::[tool.line_profiler.kernprof] and kernprof.py::_manage_profiler.__enter__()) – with the singular exception of line_profiler/_threading_patches.py which deals with enabling the profiler in a new thread, and is automatically applied by line_profiler/curated_profiling.py::CuratedProfilerContext. So there shouldn't be appreciable changes in performance unless one were to actually use the feature.

Even if a user was to use multiprocessing.dummy with kernprof --prof-child-procs, we still won't incur per-task pickling overhead, because stats are only dumped when the cache object has a ._stats_dumper – which is not the case in the main process.

pytest integration in xdoctest [...] I could try to look into that

Might have figured that out. sys.path manipulation should've happened via _pytest.pathlib.import_path(), which is in turn called by _pytest.python.importtestmodule(), _pytest.python.Module._getobj(),Module.obj, various internal methods in Module, which finally ends up being called by Module.collect(). Since your XDoctestTextfile.collect() doesn't interact with the base-class implementation, we never accessed .obj and thus the path patching didn't happen.

A naïve fix is simple (just access self.obj in your .collect()), but a caveat is that when pytest runs and all that happens, sys.path is altered with no provisions for restoration (except when it's e.g. effected by monkeypatch):¹

>>> import pytest
>>> sp = sys.path.copy()
>>> pytest.main(['--doctest-modules', '-k', 'Worker', 'tests/test_child_procs'])  # Doctest in question
...
<ExitCode.OK: 0>
>>> set(sys.path) - set(sp)
{'<...>/tests/test_child_procs/multiproc_examples', '<...>/tests'}

which IDK if it's acceptable to xdoctest, given the emphasis on being contained and getting things done with static analysis when it can be helped. But then again, if we're already interfacing with pytest we might as well lean into it; and xdoctest.plugin doesn't affect how the package functions either, when not used with pytest.

I'll write an issue and maybe a PR at xdoctest. In the meantime of course I can also fix Worker.__enter__() and Worker.__exit__() to handle the sys.path stuff.

Apropos, when writing the doctests I did occasionally run into pytest INTERNALERRORs with cryptic messages, usually when the code is slated to be on the unhappy path and when either:

• The doctest is backslash-continued, or
• The exception name in the Traceback (most recent call last):\n ...\n<xc name>: <xc message> isn't an exact match.

A bit harder to isolate those though, will ping you on that repo should I get round and make progress on that.

Other notes

llm_resource_tally notwithstanding, it still seems that we have quite a lot of heavy stuff here which are better served by separate PRs to trunk here – especially FR-1. Should I merge the whole PR nonetheless, or do you think I can just leave it open and cherry-pick the commits directly fixing pyutils#431?

Footnotes

1. Seems to be a known issue (pytest pollute sys.path,  pytest-dev/pytest#9219) that they have no intent to fix. Wondering why, doing a try-finally in pytest.main() and restoring sys.path seems like such an intuitive thing to do... but then again I guess one can argue who's to say it hasn't been changed intentionally by the test code and pytest.main() enforcing a restoration of sys.path would've been overreach. ↩

[TTsangSC]

Also since we're already looking at import-rewrite bugs (fable-review-fullrepo-*.md::F4 and F5), it may be worth keeping in the back of our minds to check if lazy imports work once 3.15rc1 is out. (But then we'll probably have bigger fish to fry with the C API; IDK though, haven't looked too closely.)

[TTsangSC]

Also noticed a problem with P12: there doesn't seem to be a portable and Python-native way to check which PIDs are active. The os functions which take PIDs requires said PIDs to be of children of the calling process, and as such are useless for inferring which .pth files are likely to be in use by other Python processes.

I can always cobble something together with ps like

import os
import subprocess
from collections.abc import Callable, Collection
from shutil import which


get_active_processes: Callable[[], set[int]]


def _find_executable(name: str) -> str:
    maybe_path = which(name)
    if maybe_path:
        return maybe_path
    raise RuntimeError(f'cannot find required executable for `{name}`')


def processes_are_alive(pids: Collection[int]) -> dict[int, bool]:
    all_pids = get_active_processes()
    return {p: p in all_pids for p in set(pids)}


def _get_active_processes_posix() -> set[int]:
    # `a`: processes from all users / `x`: include detached processes
    # Note that we don't do `aux` because we don't want the user clogging up the 1st column
    cmd = [_find_executable('ps'), 'ax']
    ps = subprocess.run(cmd, capture_output=True, text=True, check=True)
    header, *procs = ps.stdout.splitlines()
    assert header.strip().split()[0].lower() == 'pid', header
    return {int(p.strip().split()[0]) for p in procs}

But I'm really not sure about tasklist, Microsoft's docs aren't being all that helpful and I don't have a Windows machine to test. Maybe something like... ?

from csv import DictReader


def _get_active_processes_windows() -> set[int]:
    # CSV formatted output
    cmd = [_find_executable('tasklist'), '/fo', 'csv']
    tasklist = subprocess.run(cmd, capture_output=True, text=True, check=True)
    header, *rows = tasklist.stdout.splitlines()
    headers = {h.strip() for h in header.lower().split(',')}
    assert 'pid' in headers, headers
    return {int(row['pid']) for row in DictReader([header.lower(), *rows])}


if os.name == 'posix':
    get_active_processes = _get_active_processes_posix
elif os.name == 'nt':
    get_active_processes = _get_active_processes_windows
else:
    raise RuntimeError(f'unsupported platform `{os.name}`')

[TTsangSC]

More notes:

P3

P3 (HIGH, blocks merge): unwritable site-packages hard-crashes kernprof

[...]
Remediation: task PR431-3 in the plan (fallback dirs, warn-and-degrade).

Done (will push shortly), but then I realized that there probably isn't a good way for us to test that. Maybe a POSIX-only test where we chmod u-w <pure-lib dir>?

D.7

Patch-reversal verification is self-referential: tests assert restoration against the product's own Patch.summary metadata (_test_child_procs_utils.py:1594-1757), so an undeclared mutation is invisible to both sides.

IDK if there's a meaningful way to fix this; we're reliant on trusting either the programmatic declarations on Patch.summary (which insofar as SingleModulePatchs are used are guaranteed to be correct, since they are constructed with the .add_target() and .add_method() methods which automatically maintain the .summary), or maintainers to correctly update a manually-constructed table of changes every time changes are made to line_profiler._child_process_profiling. But if it bolsters confidence I can always add an explicit table of patches somewhere in _test_child_procs_utils.py and an assertion that it ≥ PATCH_SUMMARIES['maximal'].

[Erotemic]

We don't have to hit everything fable identified, just the meaningful ones.

I'm also thinking I'm not going to merge the llm-resource-tally into line-profiler directly. I have it working now so it can install as an invisible-to-git hook, and it might be better to do any tracking outside of the repo itself. Given that this repo is mature the llm usage related to it will be much lighter than projects that are entirely vibe coded, which is more of what the order of magnitude estimations it provides are useful for. For this project the measurements may be too noisy to say anything meaningful. Also the fact that any interaction I have with a chat-based service doesn't show up on it, and that is still meaningful for advancing the project - especially with GPT 5.6 out now - is something that bothers me, and I don't know how to track it well. Maybe it makes sense to tie LLM usage to the developer rather than to the repo, and I can track - and ideally mitigate - how much my own carbon footprint has increased because of my usage.

The upshot: I think this branch lives as a reference and we can cherry pick or rework any pieces of it we need into your PR or into new PRs.

Done (will push shortly), but then I realized that there probably isn't a good way for us to test that. Maybe a POSIX-only test where we chmod u-w ?

Seems doable. Having the mitigation is is more important, while it is nice, we don't have to test every corner case. But if a u-w chmod works on a posix-only test, then that's a good idea.

D.7

One thing I've noticed about LLMs is that they are overeager to build "ratchet" or "test-the-test", or "test-code-shape" tests that traditionally humans wouldn't bother to write. At first I told LLMs I was working with to stop doing it, because it seemed wasteful to me, but if you are doing a lot of agentic coding it actually does help, because it prevents the LLMs from going off the rails and undoing a previous design decision that you made. At the same time I've also seen it make bad design decisions and enforce them in tests, and then I had to argue with them to remove them and refactor. That being said, I think D.7 is safe to ignore. This isn't a project where an LLM will be able to commit anything without having it manually reviewed.

[TTsangSC]

Update: I'm more or less on the final stretch (code-wise; docs await) here except with one hiccup: concurrent.futures.

• Despite the name, ProcessPoolExecutor doesn't use a multiprocessing.pool.Pool, instead implementing similar machineries that manages multiprocessing.process.BaseProcess instances... which means that it only really has the multiprocessing.process patch, and should theoretically suffer from inconsistencies introduced by e.g. Process.terminate() like an unpatched Pool would, esp. if the parallel workload fails. But it doesn't,¹ and that's what worries me.
• Apparently Process.terminate() is only called in limited places: either explicitly via e.g. ProcessPoolExecutor.terminate_workers(), or in _ExecutorManagerThread.terminate_broken() which is run when the executor is "in a broken state" – whatever that means. So now we'll need to figure out a way to meaningfully break PPE to test any hypothetical patch for concurrent.futures. (The patch itself should be the easy part though, since we can port what we already have for multiprocessing.pool over for PPE, because they both work on a task basis.)
• Another surprising part is that I do get test failures with ThreadPoolExecutor, the equivalent of multiprocessing.dummy, which I thought line_profiler._threading_patches would've fixed. (But apparently not, since the full-repo review also had some choice words about TPE.) Will check if it's fixed with c3b2915.

Footnotes

1. Whipped up a test script which basically does the same thing as the other test modules in tests/test_child_procs/multiproc_examples and ran it through the wringer (since we're already set up in test_child_procs.py to just take whatever new test module as a fixture and run it); so far nothing has broken... as long as we're using PPE (multiprocessing-backed) and not TPE (threading-backed) – see the last bullet point. ↩

[TTsangSC]

Decided to just push so we have some progress that you/Fable can review while I work on the concurrent.futures stuff.

• I cherry-picked the two commits working on the PR work items (9f2fbf7, 07dca5c). Will probably also merge the Cython stuff (2f36f08, c3b2915) but I want to take an even closer look at that code.
• Status on the work items:
  • PR431-1:
    Merged with 9f2fbf7.
  • PR431-2:
    Merged with 07dca5c; revamped the protocol afterwards (d771ada) so that stats-reporting can reuse similar code (ac28767).¹
  • PR431-3, PR431-12:
    • Updated .pth search path; rewrote the .pth file to be more tolerant (no error messages emitted if any import failed); implemented stale-pth cleanup (f6894f4).
    • Added new test tests/test_child_procs/test_abnormal_execution.py::test_unwritable_purelib_path() for the behavior when a .pth cannot be written (ee21829).
  • PR431-4:
    Fixed with c902c29.
  • PR431-5, PR431-6:
    Fixed with e7152a6.
  • PR431-7:
    TODO
  • PR431-8:
    Removed plugin/entry-point system; multiprocessing_patches._PATCHES now constructed with the new Registry.get_default() which hard-codes the list of patches (c28cc15).
  • PR431-9:
    Fixed with 14e9ee7.
  • PR431-10:
    Fixed with c3b72a9.
  • PR431-11:
    Instead of writing to the disk every task, we now send the stats back to the main process, which does the writing at process-finalization time.¹ This exchanges disk-IO overhead with intra-process communication (pickling happens either way), so it should (hopefully) reduce the per-task overhead (ac28767).²
  • PR431-13:
    • Items 1, 5, 6:
      Fixed various lints/typos (14e9ee7).
    • Item 2:
      CacheLoggingEntry now carries an extra .level field; Cleanup.cleanup() failures now logged at the WARNING instead of DEBUG level.
    • Items 3, 7:
      Fixed with 14e9ee7.
    • Item 4:
      TODO; will code in a workaround when merging the Cython commits.
    • Item 8:
      WONTFIX at the moment, because there doesn't seem to be a consistent way to do it (nested kernprof sessions) – child processes rely on the ${LINE_PROFILER_PROFILE_CHILD_PROCESSES_CACHE_PID} envvar and the inner session would've overwritten it for the outer one, plus the inner and outer kernprof sessions could've been configured in inconsistent and irreconcilable ways.
  • PR431-T1, PR431-T4, PR431-T8, PR431-T9:
    Fixed with 4c4d2c5.
  • PR431-T2:
    Fixed with 14e9ee7.
  • PR431-T3:
    Limited scope of @cleanup_extra_pth_files; added doctest therefor (4c4d2c5).
  • PR431-T5:
    test_profiling_multiproc_script_{success,failure}() and now have one subtest running each multiprocessing start method in a true subprocess (1476d5a).
  • PR431-T6:
    • concurrent.futures:
      TODO; see previous discussions.
    • os.fork():
      Extendedtest_profiling_bare_python_{success,failure}() with os.fork() subtests (1476d5a).
    • Process.terminate():
      Added new test tests/test_child_procs/test_abnormal_execution.py::test_prematurely_terminated_process() (ee21829).
    • Corrupt .lprof:
      Added new test tests/test_child_procs/test_abnormal_execution.py::test_corrupted_child_stats_file() (ee21829).
    • os.environ:
      Updated _run_kernprof_main_in_process() to also check os.environ before and after calling kernprof.main() (1476d5a).
    • Nested sessions:
      WONTFIX; see PR431-13.
  • PR431-T7:
    WONTFIX; see previous discussions.
  • PR431-T10:
    Fixed with 4c4d2c5.
  • PR431-T11:
    Fixed with e2dd751; see also sys.path disparity between pytest --xdoc and pytest --doctest-modules Erotemic/xdoctest#207.

Welp, last pipeline failed, gotta debug.

Footnotes

1. This also fixes the bug that if a worker has already died and been replaced at pool-termination time, end-of-process cleanup/bookkeeping doesn't happen. ↩ ↩²

2. May be hard to verify with the current test suite though, because most tests run about the same number of workers and tasks. ↩

[TTsangSC]

Weird stuff, on Ubuntu the write of the .pth still went thru despite the write perms' being revoked. How is that even possible?

EDIT: I thought that maybe the spawned kernprof process inherited a writable handle to the venv's site-packages dir, but it is most probably not the case because subprocess.Popen(close_fds=...) already defaults to true.

[TTsangSC]

Update on concurrent.futures tests:

• Never mind the part about threads, I was just stupid and forgot that using Executor.map() implicitly causes tasks that haven't begun to be cancelled if earlier tasks errored out. Switching to an always-collect model like in process_test_module.py solved the issue.
• Subinterpreters (Python 3.12+; as used by InterpreterPoolExecutor (Python 3.14+)) don't work at the moment: the immediate reason is that our Cython module hasn't declared support for that yet (Allow the user to declare subinterpreter support cython/cython#6513; Cython v3.1.0+), and as a result cannot be imported in subinterpreters, e.g. those created by concurrent.interpreters.create()). Will play around a bit with the module to check if we can get that to work robustly.

EDIT: okay I give up on trying to make the Cython module work in sub-interpreters. Will just update the _line_profiler_hooks.py so that it warns instead of raising an error if _line_profiler (and hence line_profiler) can't be imported.