Re: Threads across programming languages

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.