`threading.join` does not work correctly with parameter timeout

[EgodPrime]

Bug report

Bug description:

The documentation of threading.join says 'When the timeout argument is present and not None, it should be a floating-point number specifying a timeout for the operation in seconds (or fractions thereof). '

So I try use this feature to create a time-limit execution decorator like this:

def time_limit_execution(timeout_seconds: float,):
    def wrap(func):
        def to_do(*args, **kwargs):
            def run():
                func(*args, **kwargs)
            t = threading.Thread(target=run)
            try:
                t.start()
                t.join(timeout_seconds)
                if t.is_alive():
                    raise TimeoutError(f"Execution takes more than {timeout_seconds:.2f} seconds")
            except Exception as e:
                raise e
        return to_do
    return wrap

At the beginning, it works well for my other code. Util I meet this one:

@time_limit_execution(0.1)
def func():
    return 2**1000000000
   
func()

I notice that this code takes much more than 0.1 second, and I try to directly evaluate whether it is a bug by the following:

import threading
import time

def func1():
    time.sleep(20)

def func2():
    return 2**1000000000

th = threading.Thread(target=func1)
t0 = time.time()
th.start()
th.join(1)
dt = time.time()-t0
print(f"dt of func1 is {dt}")
assert dt > 1
assert dt < 2

th = threading.Thread(target=func2)
t0 = time.time()
th.start()
th.join(1)
dt = time.time()-t0
print(f"dt of func2 is {dt}")
assert dt > 1
assert dt < 2

which ouputs (Also replayed in Google Colab):

dt of func1 is 1.0007781982421875
dt of func2 is 10.11729907989502
---------------------------------------------------------------------------
AssertionError                            Traceback (most recent call last)
[<ipython-input-1-8d922cdc60b7>](https://localhost:8080/#) in <cell line: 26>()
     24 print(f"dt of func2 is {dt}")
     25 assert dt > 1
---> 26 assert dt < 2

AssertionError:

I tried reading the source to figure out if there are some limits about threading.join, which points to _thread._ThreadHandle.join used in cpython/Lib/threading.py, implemented in cpython/Modules/_threadmodule.c, but the C code is too complex for me to understand.

So I wonder know whether it is a bug and whether it will be fixed soon.

CPython versions tested on:

3.9, 3.10, 3.11, 3.12, 3.13

Operating systems tested on:

Linux

[colesbury]

I don't think this is an issue with thread.join(). Python continues to hold the GIL while executing 2**1000000000 so the other thread doesn't have an opportunity to return from t.join(timeout_seconds) until the computation completes.

[EgodPrime]

So it seems GIL is the trouble maker :). And now I wonder is there a possible way to make it work? (Except for compiling Python in no-GIL mode)

[picnixz]

And now I wonder is there a possible way to make it work?

I haven't tested whether my solution would work, but a naive way is to use a separate process and kill it after X seconds. You can pass around values between processes (see multiprocessing docs for that). You can also look at an executor's pool instead.

And AFAIK, there's no way to do it with threads.

[EgodPrime]

It would be frustrating if I have to use multiprocessing since creating a new process for each executing would slow down my program from thousands per second to tens per second.

My earlier solution is to use signal:

def watch(timeout_seconds: float):
    def handle_timeout(signum, frame):
        raise TimeoutError(f"Execution takes more than {timeout_seconds:.2f} seconds")

    def wrap(func):
        def to_do(*args, **kwargs):
            signal.signal(signal.SIGALRM, handle_timeout)
            try:
                signal.setitimer(signal.ITIMER_REAL, timeout_seconds)
                func(*args, **kwargs)
            except TimeoutError as e:
                signal.setitimer(signal.ITIMER_REAL, 0)
                raise e
            except Exception as e:
                signal.setitimer(signal.ITIMER_REAL, 0)
                raise e
                
        return to_do

    return wrap

However, it goes into a mess when my program becomes running concurrently. And that's why I tried to utilizing threading.join with timeout.

[picnixz]

Unfortunately, that's how (Python) threading works. AFAIK, it's not possible to interrupt a thread when an "atomic" operation is being done (that is, you cannot interrupt a line of code like if you didn't finish executing that line). In general, if you expect noon-trivial arithmetic like that to be "cancellable", then you likely need to either break down differently or to rewrite the arithmetic in parts that can be interrupted.

Can you provide what you really want to do in production (I doubt you want to compute 2**1000000000, but if it's what you really want, then I'd like to know in which circustumances you need that kind of operation).

[EgodPrime]

Thanks, my production is to excute AI-generated testing code as fast as possible to evaluate the security features of some libraries. That's why I need to make sure the time of each execution is limited. The code of computing 2**1000000000 is a real case generated by AI that makes my program suddenly slow down.

I can see what you mean by 'that's how (Python) threading works', and I don't think there is a need to create such "cancellable" operations for my circustumance (since 2**1000000000 is just one case, while I can expect there would be a lot of other similar cases).

Maybe I can try build python without the GIL in 3.13 to solve this issue. But I'm not sure if without GIL, whether a thread can have an opportunity to return from t.join(timeout_seconds) when it is doing some "atomic" operation. Anyway, I can have a try first.

[EgodPrime]

I've tried the Python3.13 without gil, and this issue is partially solved.

import threading
import time

def func1():
    time.sleep(20)

def func2():
    return 2**1000000000

th = threading.Thread(target=func1)
t0 = time.time()
th.start()
th.join(1)
dt = time.time()-t0
print(f"dt of func1 is {dt}")
assert dt > 1
assert dt < 2

th = threading.Thread(target=func2)
t0 = time.time()
th.start()
th.join(1)
dt = time.time()-t0
print(f"dt of func2 is {dt}")
assert dt > 1
assert dt < 2

dt of func1 is 1.0006165504455566
dt of func2 is 1.000669002532959

Now the above code would not raise an AssertionError, and the dt of func2 seams correct. However, it totally takes more than 2 seconds to execute the code. I guess the Python has to wait for all threads done their jobs before it can exit. Anyway, the second thread can now correctly return when the time limit is reach.

Here is the environment:

~/cpython# ./python -VV
Python 3.13.1+ experimental free-threading build (heads/3.13:fe08cdf, Dec 17 2024, 11:59:40) [GCC 11.4.0]

~/cpython# time ./python x.py
dt of func1 is 1.0006165504455566
dt of func2 is 1.000669002532959

real    0m20.238s
user    0m9.934s
sys     0m1.641s

[picnixz]

I guess the Python has to wait for all threads done their jobs before it can exit.

Yes, and that you need to clean-up resources, waiting for the OS, etc. So you should consider this and not expect that the timeout would be necessarily 2s. Note that there are still some parts of the code that are not fully without the GIL; we just remove the GIL where we can remove it.

Considering this, I think this issue can be closed as not an issue, but can be considered as "half-fixed" on your side. WDYT?

[EgodPrime]

sure, thanks a lot!