Question: how does concurrent interleave?

History

1. Anton opened the ticket 2026-09-25 06:20
2. Anton changed the state review 2026-09-25 06:20
3. Caramboleyo commented 2026-09-25 06:48

   what does it mean it swicthes?

4. Anton commented 2026-10-01 22:10

   Sorry, this sat unanswered. "Switches" means the moment one item of a concurrent stops running and another one continues.

   Measured today with this program:

   step(String name, Number i) { echo(name + i)  return i }
   count(String name) { step(name, 1)  step(name, 2)  step(name, 3)  return name }
   r = concurrent [ count('A'), count('B') ]

   • Interpreter and --native binary: A1 A2 A3 B1 B2 B3. An item runs until it really waits (timer, fetch, socket, file). Only then does the next one get a turn.
   • JS target: A1 B1 A2 B2 A3 B3. Every call is awaited there, so every call is a turn change. The items alternate at each call even when nothing waits.

   The results are the same (['A','B']). Only the order of side effects in between differs. My recommendation: the interpreter's rule (switch only where a call really waits). It is cheaper, predictable, and already what two of three engines do. The JS target then changes to match. Yes or no?

5. Caramboleyo commented 2026-10-01 22:11

   Concurrent means they run at the same time, both options do not sound like that

6. Anton commented 2026-10-01 22:13

   Agreed: neither engine really runs them at the same time today. Both only take turns on one core. Proposal for real concurrency:

   • Each item of a concurrent runs at the same time as the others, on its own core (the same thread machinery isolates already use).
   • An item works on copies of what it reads from outside (the language already copies by default). It cannot write outer variables; it hands back its result. The block form's users = fetchUsers() assigns when all items are done.
   • The order of side effects between items (echo, writes to a db) is not defined. Code that needs an order does not use concurrent.
   • The JS target uses Web Workers where the item has no DOM access, and turns otherwise.

   Yes, or what should differ?

7. Caramboleyo changed the state open 2026-10-01 22:15

   Concurrent was ment to work like Promise.all

8. Anton commented 2026-10-01 22:18

   Understood, like Promise.all. That withdraws my "own core" proposal (that would be parallel). So: all items start at once; while one waits, the others run; the result is the list of results in item order; one failing item fails the whole concurrent (already so since 4bed0fef). The order of side effects between items is not part of the language, as with Promise.all. So the interpreter and the JS target are both correct, and nothing needs to change. Real parallel work stays with isolates. Setting this to review.

9. Anton changed the state review 2026-10-01 22:18