Re: Threads across programming languages

On 05/03/2024 12:33 PM, Ross Finlayson wrote:

On 05/02/2024 07:25 PM, Lawrence D'Oliveiro wrote:

On Thu, 2 May 2024 16:58:54 -0700, Chris M. Thomasson wrote:
>

The CPU can become a bottleneck.

>
Then that becomes an entirely different situation from what we’re
discussing.
>

So, there is no way to take advantage of multiple threads on Python?

>
There is, but the current scheme has limitations in CPU-intensive
situations. They’re working on a fix, without turning it into a memory
hog
like Java.
>

>
>
Yeah, it can be that way. "How are things?" "Yesterday
I implemented an entire web service on the cloud."
"Oh, really, how'd that go?" "I opened Initializer and
added a starter and copied how to pop the queue
and put the queue name in a file, then I added it
to git and it went into the CICD pipeline and now
it's in Prod." "Great." "It only even needs 1 gigabyte of RAM."
>
Surely when it's like, "the only time this framework app
uses 1 gigabyte of RAM is at boot time it totally templates
itself into a gigabyte of RAM", then the guy's like "see,
I'm totally not using RAM." Yet it's like, "well, yeah,
but the meter for the RAM you're not using is on".
>
>
>
At least then for re-routines, and if it helps it's quite
an idee fixe at this point, it's clear as described they can
be implemented in most languages with or without
threads as with just a minimum of threads and thread
locals and exception handling being well-defined and
the most usual sort of procedural call stack, then,
get this: taking plain usual code, giving it a ton of
threads, making every invocation one of these things,
and automatically parallelizing the code automatically
according to the flow-graph dependencies declared
in the synchronous, blocking, routine.
>
Now _that's_ ridiculous.
>
Though, in C++ with this sort of approach, the only
sort of "unusable" object is a future<result<T, E>>
as it were, or "the ubiquitous type" sort of thing
then as to overload its access as to invoke "get()",
if there was a sort of way to overload the "." and "->"
operators, and have them most simply be compiled
as invoke "." and "->". Does std::identity work this way?
>
>
>
>

I read there's some C++ proposals to make for overloading
the "." operator in C++ 20, then though I'd still wonder
how to essentially make a wrapper class that dispatches all
its accesses to, ..., functions, or as with regards
to run-time-type-identification, with regards to
making a future<result<T, E>> that is indistinguishable
to auto or is a correct type according to the various
rvalues the assignable lvalue, that otherwise passes
everything through "." as through ".get()." and as
through "->" as through "->get().", as for something
like an "experimental:hidden_future<T, E>" as then
for an "experimental:unusable<T>" for re-routines,
unobtrusively otherwise in the language.
In C it would sort of be according to whatever
defines the struct or context or what's usually
otherwise a class, for "idiomatic_boxed" then
as for having "include offsets" to these types,
then as with regards to C language support as
via setjmp/longjmp I suppose or other notions
that effect stack-unwinding as with handler blocks.
For re-routines, ....
It's like when you're writing a react app, and
it's just a JavaScript that includes a file, so
if you make enough of a model of browser-dom,
not rendering and the whole bit but just browser-dom,
then implement, "the algorithm", with the usual idea
of a unidirectional single-page app, then it can
have its units tests all figured out from just pointing
to a different include file with otherwise matching
the interface. Then there were added fibers and hooks
and this kind of thing, if at all complicating
the, "algorithm", all courtesy browser-dom, and UI events,
and my favorite, form events. I don't have one of those
but there's something to be said that just implementing
in-memory what effects is its world