Investigate macroTasking

[jeswr]

Note to self for now:

See if we can remove macroTasking behavior - in particular see if we are able to do something like the following after fixing autoStart behavior

// Returns a function that asynchronously schedules a task
export function createTaskScheduler() : TaskScheduler {
  if (typeof queueMicrotask === 'function')
    return queueMicrotask;

  const r = Promise.resolve(undefined);
  return (task: Task) => { r.then(task) }
}

[rubensworks]

For reference, there's a long history behind this: #13

[RubenVerborgh]

Back in my days we used to DoEvents, my friends 👴
Also relevant is #29.

But given this history, shall we stick to the existing behavior, @jeswr?

[jeswr]

Most likely - but I would still like to leave this open to investigate. This is because issue of "As discovered in comunica/comunica#826, some use cases may lead to extensive microtask usages" may be resolved in https://github.com/RubenVerborgh/AsyncIterator/tree/breaking/v4 by doing things like ensuring that readable events can only be queued once per-tick per-iterator; and also skipping unecessary readable events on chained iterators.

[RubenVerborgh]

Gotcha; I do however think that:

1. There might always exist long chains of events, which result in long event queues that need interrupting (just like long recursion can also always occur in synchronous programming)
2. We might not want clients to bind on microtask semantics

But if we can conclusively disprove 1, then I'm happy to go ahead.

[RubenVerborgh]

Actually the more relevant issue is #17 (comment), sorry. #29 only changed the kind of macrotask.