Hi, Here's my input, FWIW:
The use cases provided in opposition to this change are very bad > ideas. In all of the cases presented, what you actually want is > either a separate thread of execution or an idle listener; *not* a > maximum-priority scheduled task in the current thread. People > sometimes use setTimeout(fn,0) in the browser for CPU-intensive > operations, **because there is no other choice**, but even in those > cases, it's better to use WebWorkers instead, now that they are pretty > widely supported. > I think this is too simplistic a view. The issue isn't that people are doing compute-intensive tasks like calculating fibonacci numbers; they are processing application state, which involve collections of indefinite size, and this state is necessarily in the current isolate. The work can't be offloaded into a child process. There is a legitimate need, IMO, to be able to perform some processing on those indefinitely-size collections without stalling the event loop for an indefinite time - even if that time is "only" an unbounded number of microseconds, so to speak. This requires some way of scheduling some work to be done, after completion of the current work, without preempting the handling of (IO and other) events that have occurred during the processing of the current work. The bugs we're seeing in node-core are not just in node-core. Any > library that uses nextTick for its *intended purpose*, to defer > execution until after the current run-to-completion, but before > normal-priority IO events have a chance to fire, will find that they > have the same sporadic bugs at scale. > This is clearly a fatal problem that needs to be fixed. > The real source of this problem is that the concept of a "tick" is > pretty loosely defined in Node, and not very well understood. As a > result, a lot of people have come up with their own (mostly wrong) > beliefs about how it works, and have built libraries around those > beliefs. The semantics are too complicated to get right all the time, > and we're seeing the results of that. > Quite. Of all of the unfortunate things about nextTick, the name is the most unfortunate. The word 'tick' implies that there is some periodic time interval, and nextTick defers things until that time interval has elapsed. Anyone sensible encountering it for the first time will surely know that it would be insane for things to work that way, so he must then conclude that he has no clue about what it *actually* does; and as we know the docs don't help. If we had a clean sheet of paper - which we don't, of course - then none of the APIs would have the word 'tick' in them because it can only be misleading. So, it seems to me we do need: a) "process_before_already_scheduled_events" - to address the main use-case, which is Isaac's proposed behaviour for nextTick; b) "schedule_after_already_scheduled_events" - to address the use case of being able to schedule work in parcels that would otherwise preempt event processing for unbounded time. (a) is a critical need, and the "official" purpose of nextTick, so its current behaviour is broken and it needs fixing to behave this way. There is an option to introduce a new more meaningful name and deprecate nextTick; but even then nextTick is obviously never going to go away, so it just needs to be very carefully documented and the name explained as an unfortunate artifact of history. (b) I believe is a genuine need and hopefully we can think of a good name for it, and implement it. Paddy
