Lets Talk about performance, did you know the Global Interpreter Lock (GIL)?

[oseasandrepro]

OK, I am not an everyday Python developer, I already know that python is slow. And now I find out the GIL.

A global interpreter lock (GIL) is a mechanism used in computer-language interpreters to synchronize the execution of threads so that only one native thread (per process) can execute basic operations (such as memory allocation and reference counting) at a time.
[1] As a general rule, an interpreter that uses GIL will see only one thread to execute at a time,
even if it runs on a multi-core processor,...

In-text: (“Global interpreter lock”)

So, essentially in python we do not have real multicore by default, CPU bounded application are affected!.

But...
If the GIL is the villain, the multiprocessing the module is the superhero. Instead of threads,
it spawns separate processes, each with its own GIL-free Python interpreter.
Result: True parallelism! Your CPU cores actually break a sweat.
But beware: multiprocessing comes with overhead
(like spawning processes and inter-process communication), making it less efficient for lightweight tasks.
And
Breaking News: GIL is Leaving the Chat!
In Python 3.12 and beyond, there’s hope on the horizon. PEP 703, the proposal to make the GIL optional, is now under development.
The new design will use finer-grained locking, reducing contention and allowing multiple threads to execute Python code in parallel.

In-text: ("The Python Global Interpreter Lock (GIL): An (Almost) Love Story")

And
Python 3.14 release came with an GIL-free version.
GIL-free is not always better.
An interesting point to note is that on this last test, I also tried it with a multiprocessing version of the code. It turned out that the regular Python was significantly faster (28%) than the GIL-free Python. I won’t present the code, just the results,
In-text: ("Python 3.14 and the End of the GIL")

So, the stable version of python still use GIL, if free-GIL do not become the standard,
the question is How GIL affect the Lib performance? Since it uses multiple thread.
And when end the responsibility on performance of the Lib, and we start to rely on the developer of the server side that indeed implement the procedures?

[oseasandrepro]

I just find a pretty good tutorial about GIL, check it out:
What Is the Python Global Interpreter Lock (GIL)?

"...But keep in mind that as a Pythonista you’re usually only affected by it(the GILL) if you are writing C extensions or if you’re using CPU-bound multi-threading in your programs."

[oseasandrepro]

Answering the question "How GIL affect the Lib performance?"

Will affect the lib performance when the procedures call mix CPU-bound and IO-bound procedures, since all threads are treated as IO-bound - the default of multithreaded in Python

In code below, in server stub, we can see that raw threads, with threading.Thread module, are used to listen for each procedure.
And managed thread, with ThreadPoolExecutor, to effectively handle(compute) each request.

Both are bound by Python’s Global Interpreter Lock (GIL).
Neither provides true parallelism for CPU-bound tasks — only for I/O-bound or blocking operations.

#srpc_server_stub_gen.py
   ...
    def __listen_for_func(self, func_name):
        with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
            s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
            s.bind((self.__host, 0))
            port = s.getsockname()[1]
            self.__register_func_in_binder(func_name, port)
            s.listen()
            s.settimeout(1.0)

            while not self.__stop_event.is_set():
                try:
                    conn, addr = s.accept()
                    self.__executor.submit(self.__handle_request, func_name, conn, addr)
                except socket.timeout:
                    continue
                except Exception as e:
                    self.__logger.error(f"An error occurred while listening for function [{{func_name}}] in port [{{port}}]: {{e}}")
                    os._exit(1)
...
    def start(self):
        stop_event = threading.Event()
        binder_thread = threading.Thread(target=self.__binder.start_binder, name="binder_thread", daemon=True)
        binder_thread.start()
        try:
            for func_name in self.__lib_procedures_name:
                t = threading.Thread(None,
                    target=self.__listen_for_func,
                    name=f"Thread-Listener-for-func-{{func_name}}",
                    args=[func_name]
                    )
                self.__threads.append(t)
                t.start()
            self.__logger.info(f"SRPC server started [tcp-{{self.__host}}-{DEFAULT_BINDER_PORT}]. press Ctrl+C to stop")
            stop_event.wait()
        except KeyboardInterrupt:
            self.stop()
        except Exception as e:
            self.__logger.error(f"An error occurred while starting the server stub: {{e}}")
            self.__logger.error("Mission aborted.")
            os._exit(1)

[oseasandrepro]

Proposed architecture

[oseasandrepro]

The binder thread can run in one core(another interpreter/ another process) and the "call listener" in another.

[oseasandrepro]

The proposed architecture only separate one core for binder thread and another for the procedures call. We still will have problems with procedures call mixing CPU-bound and IO-bound.

We can segregate IO and CPU bounds procedures, using "annotation" that come with the Lib, so IO-bound procedures will going to use 'threading.Thread' and CPU-bound procedures, going to use 'multiprocessing'.
Python's multiprocessing module enables true parallelism by creating separate processes that bypass the Global Interpreter Lock (GIL), making it ideal for CPU-bound tasks. Each process has its own memory space, unlike multithreading, which runs concurrently within a single memory space.

The challenge is the separated memory space - can be challenge to exchange messages between the main process and the fired process for each CPU-bound procedure. And we need to have in mind the latency between process communication.
And the cost will be the memory, one separated process for each CPU bound procedure.

We also need to be aware of a "metrics thread" - the one that write the metrics in a file - can be IO-bound thread that waits for data to write in disk or "send to grafana"