Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.lang.c++,comp.lang.c
Subject: Re: Threads across programming languages
Date: Fri, 3 May 2024 18:05:33 +0300
Organization: A noiseless patient Spider
Lines: 84
Message-ID: <20240503180533.000017ff@yahoo.com>
References: <GIL-20240429161553@ram.dialup.fu-berlin.de>
	<v0ogum$1rc5n$1@dont-email.me>
	<v0ovvl$1ur12$4@dont-email.me>
	<v0p06i$1uq6q$5@dont-email.me>
	<v0shti$2vrco$2@raubtier-asyl.eternal-september.org>
	<v0spsh$31ds4$3@dont-email.me>
	<v0stic$325kv$3@raubtier-asyl.eternal-september.org>
	<v0svtn$32o8h$1@dont-email.me>
	<v0t091$32qj6$1@raubtier-asyl.eternal-september.org>
	<v0u90h$3c1r5$4@dont-email.me>
	<v0v7rf$3lu04$1@dont-email.me>
	<v0v8u3$3m7rm$1@dont-email.me>
	<v10t0v$20cs$1@dont-email.me>
	<v116q4$4at1$1@dont-email.me>
	<v119bu$4pfa$1@dont-email.me>
	<v127i4$ej9d$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Injection-Date: Fri, 03 May 2024 17:05:37 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="24f79386f11d1cfdbf24e001dc1c4c6c";
	logging-data="624660"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19KuRqeDji4zbM0YEkg6GW0mLaUoaq4Jyo="
Cancel-Lock: sha1:bNNyuiwBhPhtIF3VZ27vNggPJqI=
X-Newsreader: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32)
Bytes: 4681

On Fri, 3 May 2024 10:34:11 +0200
David Brown <david.brown@hesbynett.no> wrote:

> On 03/05/2024 01:58, Chris M. Thomasson wrote:
> > On 5/2/2024 4:15 PM, Lawrence D'Oliveiro wrote: =20
> >> On Thu, 2 May 2024 13:28:15 -0700, Chris M. Thomasson wrote:
> >> =20
> >>> On 5/1/2024 10:39 PM, Lawrence D'Oliveiro wrote: =20
> >>>>
> >>>> On Wed, 1 May 2024 22:20:47 -0700, Chris M. Thomasson wrote:
> >>>> =20
> >>>>> On 5/1/2024 1:34 PM, Lawrence D'Oliveiro wrote:
> >>>>> =20
> >>>>>> Remember, we=E2=80=99re talking about maximizing I/O throughput he=
re,
> >>>>>> so CPU is not the bottleneck. =20
> >>>>>
> >>>>> It can be if your thread synchronization scheme is sub par. =20
> >>>>
> >>>> Another reason to avoid threads. =20
> >>>
> >>> Why? Believe it or not, there are ways to create _highly_ scalable
> >>> thread synchronization schemes. =20
> >>
> >> I=E2=80=99m sure there are. But none of that is relevant when the CPU
> >> isn=E2=80=99t the bottleneck anyway. =20
> >=20
> > The CPU can become a bottleneck. Depends on how the programmer=20
> > implements things.
> >=20
> >  =20
> >>>> So long as your async tasks have an await call somewhere in
> >>>> their main loops, that should be sufficient to avoid most
> >>>> bottlenecks. =20
> >>>
> >>> async tasks are using threads... No? =20
> >>
> >> No. They are built on coroutines. Specifically, the =E2=80=9Cstackless=
=E2=80=9D
> >> variety.
> >>
> >> <https://gitlab.com/ldo/python_topics_notebooks/-/blob/master/Generato=
rs%20&%20Coroutines.ipynb?ref_type=3Dheads>
> >> =20
> >=20
> > So, there is no way to take advantage of multiple threads on
> > Python? Heck, even JavaScript has WebWorkers... ;^) =20
>=20
> Python supports multi-threading.  It uses a global lock (the "GIL")
> in the Python interpreter - thus only one thread can be running
> Python code at a time.  However, if you are doing anything serious
> with Python, much of the time will be spend either blocked (waiting
> for network, IO, etc.) or using compiled or external code (using your
> favourite gui toolkit, doing maths with numpy, etc.).  The GIL is
> released while executing such code.
>=20
> Thus if you are using Python for cpu-intensive work (and doing so=20
> sensibly), you have full multi-threading.  If you are using it for=20
> IO-intensive work, you have full multi-threading.  It's not going to
> be as efficient as well-written compiled code, even with JIT and
> pypy, but in practice it gets pretty close while being very
> convenient and developer friendly.
>=20
> If you really need parallel running of Python code, or better
> separation between tasks, Python has a multi-processing module that
> makes it simple to control and pass data between separate Python
> processes, each with their own GIL.
>=20
>=20
>=20

A typical scenario is that you started you python program while
thinking that it wouldn't e CPU-intensive. And then it grew and became
CPU-intensive.
That's actually a good case, because it means that your program is used
and is doing something worthwhile.