Re: Threads across programming languages

On 29.04.2024 18:19, Stefan Ram wrote:

paavo512 <paavo@osa.pri.ee> wrote or quoted:
|Anyway, multithreading performance is a non-issue for Python so far as
|the Python interpreter runs in a single-threaded regime anyway, under a
|global GIL lock. They are planning to get rid of GIL, but this work is
|still in development AFAIK. I'm sure it will take years to stabilize the
|whole Python zoo without GIL.
    The GIL only prevents multiple Python statements from being
   interpreted simultaneously, but if you're waiting on inputs (like
   sockets), it's not active, so that could be distributed across
   multiple cores.
    With asyncio, however, you can easily handle the application
   for threads to "wait in parallel" for thousands of sockets in a
   single thread, and there are fewer opportunities for errors than
   with multithreading.

In C++, async io is provided e.g. by the asio library.
Just for waiting on thousands on sockets I believe a single select() call would be sufficient, no threads or asio is needed. But you probably meant something more.

    Additionally, there are libraries like numpy that use true
   multithreading internally to distribute computational tasks
   across multiple cores. By using such libraries, you can take
   advantage of that. (Not to mention the AI libraries that have their
   work done in highly parallel fashion by graphics cards.)
    If you want real threads, you could probably work with Cython
   sometimes.

Huh, my goal is to avoid Python, not to work with it. Unfortunately this (avoiding Python) becomes harder all the time.

    Other languages like JavaScript seem to have an advantage there
   because they don't know a GIL, but with JavaScript, for example,
   it's because it always runs in a single thread overall. And in
   the languages where there are threads without a GIL, you quickly
   realize that programming correct non-trivial programs with
   parallel processing is error-prone.

Been there, done that, worked through it ... 15 years ago. Nowadays non-trivial multi-threaded parallel processing in C++ seems pretty easy for me, one just needs to follow some principles and take care to get the details correct. I guess it's about the same as memory management in C, one can get it correct with taking some care. In C++ I can forget about memory management as it is largely automatic, but for multithreading I still need to take care.