On May 31, 2012, at May 31, 20121:05 PM, Paddy Byers wrote: > 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.
Neither approach is correct. If a collection is of "indefinite size" then it should not be loaded entirely in to memory in order to accomplish computation, it should be streamed. In the case of streaming the collection you can iteratively perform the computation without locking up the process indefinitely and without taking on a large memory footprint of either the original collection or even what has already been processed. > > 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
