Path: ...!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!raubtier-asyl.eternal-september.org!.POSTED!not-for-mail
From: Bonita Montero <Bonita.Montero@gmail.com>
Newsgroups: comp.lang.c++,comp.lang.c
Subject: Re: Threads across programming languages
Date: Thu, 2 May 2024 13:22:39 +0200
Organization: A noiseless patient Spider
Lines: 27
Message-ID: <v0vt1v$3qlsf$1@raubtier-asyl.eternal-september.org>
References: <GIL-20240429161553@ram.dialup.fu-berlin.de>
 <RPidnQT6TOLEU7L7nZ2dnZfqnPWdnZ2d@giganews.com>
 <RsudnRRDUtiEcbL7nZ2dnZfqnPednZ2d@giganews.com>
 <gmWdnYejrq5snq77nZ2dnZfqn_GdnZ2d@giganews.com>
 <v0vd0a$3n0k7$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 02 May 2024 13:22:39 +0200 (CEST)
Injection-Info: raubtier-asyl.eternal-september.org; posting-host="fc01b5cced46b9bd2db0b176923fffe4";
	logging-data="4020111"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19YVoqb5m2LwjSLKyXXJBd7bIB99/bMr2Q="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:be1IhoWYWqgQCN/6mbs1zJX+TuQ=
In-Reply-To: <v0vd0a$3n0k7$3@dont-email.me>
Content-Language: de-DE
Bytes: 2769

Am 02.05.2024 um 08:48 schrieb Lawrence D'Oliveiro:
> On Wed, 1 May 2024 20:09:48 -0700, Ross Finlayson wrote:
> 
>> So, the idea of the re-routine, is a sort of co-routine. That is, it
>> fits the definition of being a co-routine, though as with that when its
>> asynchronous filling of the memo of its operation is unfulfilled, it
>> quits by throwing an exception, then is as expected to to called again,
>> when its filling of the memo is fulfilled, thus that it returns.
> 
> The normal, non-comedy way of handling this is to have the task await
> something variously called a “future” or “promise”: when that object is
> marked as completed, then the task is automatically woken again to fulfil
> its purpose.

The problem with a future and a promise is that in most languages you
can't wait for multiple futures at once to have out of order completion.
So if you have a server application futures are easy to use, but mostly
less efficient.
I never think about futures and I have my own thread pool class to which
I dispatch my function-objects. These respond o a generic queue which
can handle the responses out of order and can also handle different
states than a completion. That's what you usually need with a server
application.
For me promises and futures are mostly for educational purposes as the
first step to show how asynchronous operations work to proceed to more
efficient solutions later.