Scheduler name bike-shedding

[benlesh]

Currently the trampoline scheduler is named immediate, and the microtask scheduler is named nextTick. There is als

I propose that we rename immediate to sync. I say this because immediate sort of implies that the scheduled action is going to take place right away, and that's not really true. It's going to be bumped from it's current call stack and executed next, but synchronously.

For nextTick, it's a little more debatable, it's pretty aptly named, but I think it would be more descriptive if it were named microtask, because ultimately that's the goal. To schedule it as a microtask after the current frame but before things like setTimeout.

... which brings me to another thing, we don't have a scheduler based off of setTimeout or requestAnimationFrame. The latter is DOM-specific, but given that we're modular now, I think there's grounds for including it in this library, it's an important scheduler.

Once we land on these names, I'll be writing some improved documentation on the matter.

[staltz]

I see no objections to this...

[benlesh]

In talking to @chriscareycode, @abersnaze and @stealthcode at Netflix, there were a few other options presented for names around immediate in particular:

• queueImmediate: because it gives users the sense that scheduled items are being buffered in some way.
• trampoline: because it's a brand new word with no connotations in the JS community which may make it more memorable, and describes what it does in a way that can be googled.
• jenga: because it topples the call stack over with in the same event on the event loop. Again, descriptive and memorable.
• immediate: less favored because people have some idea in their heads of what "immediate" means.
• sync: Because you're scheduling, but it's synchronous. This was less well recieved.

... all parties thought that currentThread didn't make any sense to them because of JavaScript's lack of "real" multithreading.

[staltz]

Trampoline sounds the best IMO.

[kwonoj]

+1 for trampoline and 'currentThread didn't make sense ' both. (intrigued into 'jenga' for sec..)

[benlesh]

I'd be interested in thoughts from @zenparsing, @domenic, @wycats or @stefanpenner on this, as well. I'm sure this sort of scheduling has come up in conversations at the TC39, and they might have more specific vernacular we could leverage.

[mattpodwysocki]

@Blesh that's been the problems with transporting the names from runtime to runtime. CurrentThread has a history of doing recursive scheduling right, placing things in the right order whereas the immediate was indeed immediate.

Consider the difference:

const Scheduler = require('rx').Scheduler;

Scheduler.currentThread.schedule('bye', (self1, state1) => {
  self1.schedule('hi', (self2, state2) => console.log(state2));
  console.log(state1);
});
// => bye
// => hi

Whereas the immediate scheduler would do the following:

const Scheduler = require('rx').Scheduler;

Scheduler.immediate.schedule('bye', (self1, state1) => {
  self1.schedule('hi', (self2, state2) => console.log(state2));
  console.log(state1);
});
// => hi
// => bye

[mattpodwysocki]

@Blesh had I done it over again, I would have the following:

• Scheduler.asap for using the fastest transport mechanism available in a non-blocking fashion
• Scheduler.async for slower mechanisms such as setTimeout etc
• Scheduler.immedate once again for immediate scheduling
• Scheduler.sync for synchronous scheduling that would once again mimic the current thread implementation.

Trampoline is not a word I'd like to put into my API as it's an implementation detail that they don't really need to know nor care about.

[benlesh]

that's been the problems with transporting the names from runtime to runtime. CurrentThread has a history of doing recursive scheduling right, placing things in the right order whereas the immediate was indeed immediate.

I completely get it.

For RxJS 5, we've had the lack of a scheduler mean "immediate" as in "no scheduling at all, just call it".

Scheduler.asap for using the fastest transport mechanism available in a non-blocking fashion
Scheduler.async for slower mechanisms such as setTimeout etc
Scheduler.immedate once again for immediate scheduling
Scheduler.sync for synchronous scheduling that would once again mimic the current thread implementation.

I sort of like asap, for the "microtask" scheduler, but it's not really "as soon as possible". In fact, it conflicts a little with async, since it is indeed "async". I think timeout was never a bad name for a 100% setTimeout-based implementation of a scheduler.

[mattpodwysocki]

@Blesh and for the most part, RxJS v4 has done the same with immediate, bypassing when specified and just returning an empty Disposable since it wasn't really capable of being cancelled anyhow.

[zenparsing]

From my point of view the only kind of scheduling that makes sense is "job queuing" (called microtask queue elsewhere). : \

[zenparsing]

Therefore I don't see the point in all of these different (and confusing) names.

[benlesh]

Therefore I don't see the point in all of these different (and confusing) names.

Suppose you want to synchronously traverse a tree recursively and the tree is 1000 levels deep.

... that's why there is more than one scheduler. :)

[mattpodwysocki]

@zenparsng where you are coming from and where we are, are two different spots. There is the want, especially on the ES-Observable, to make everything async, hence the microtask. Here, we want the swappable concurrency layer to choose which is right for us, like requestAnimationFrame, nextTick, setImmediate or queued as it were.

[trxcllnt]

@Blesh btw I have the RequestAnimationFrame Scheduler in a branch.

[benlesh]

@trxcllnt ... well PR that thing! 😝

[trxcllnt]

@Blesh still needs tests ;-)

[benlesh]

Okay, I think where this has landed is:

RxJS 4	RxJS 5 (current)	RxJS 5 (after)
Scheduler.immediate	null or undefined	Scheduler.none, null or undefined
Scheduler.currentThread	Scheduler.immediate	Scheduler.sync
Scheduler.default	Scheduler.nextTick	Scheduler.asap
Scheduler.timeout	N/A	Scheduler.timeout
Scheduler.requestAnimationFrame (Rx-DOM)	N/A	Scheduler.animationFrame

Is this acceptable? @mattpodwysocki @kwonoj @staltz @trxcllnt?

[benlesh]

... the ideal being no name change, or no conflicting names (immediate is different in RxJS 4 and 5 currently)

[trxcllnt]

@Blesh I like these names

[benlesh]

Some clarification on sync:

Every other scheduler is async, really*. The only other "synchronous" scheduling is no scheduling at all (Scheduler.none), so Scheduler.sync could only be the trampoline scheduler.

* virtual scheduling can be synchronous, but it's manual and we're not talking about that one.

[kwonoj]

Those names looks good to me.

[staltz]

I just don't like asap because it gives me the idea using it will schedule actions even before sync does. (However sync is even sooner than "as soon as possible")

I get the point that nextTick isn't always accurate, but asap doesn't capture the idea either.

Perhaps soon or queue? This way we even avoid the acronym, since all the remaining names are actual words.

[zenparsing]

I just don't like asap

In the ES spec world, we call these things "jobs" and we have a "job queue".

[benlesh]

Scheduler.job? Is job common enough vernacular?

[benlesh]

Talking with @jhusain, he brought up a valid point, that by strict definition of "synchronous", the trampoline scheduler is not "sync" because it schedules on the next call stack. Being in the same event in the event loop doesn't really mean "synchronous" in the strictest sense of the word. For example, if you're inside of an action scheduled on the trampoline scheduler, and it's currently running, and you schedule from within that action, it's going to complete your current action before it runs the one you just scheduled. That's not synchronous.

Interestingly, it sheds more light on the name currentThread, even though that still doesn't make sense for JavaScript.

Also, @jhusain reiterated what @zenparsing said above, which is in the ES community the "microtask" queue is generally called a "job", but he also liked the name "trampoline".

So now a new proposal:

RxJS 4	RxJS 5 Current	RxJS 5 Proposed
immediate	undefined	undefined or none
currentThread	immediate	currentJob? trampoline?
default	nextTick	nextJob? job? asap?

[benlesh]

Right now I'm inclined to say currentJob and nextJob, as they meet the ES vernacular, and seem to accurately describe what is going on.

@stealthcode brought up the point that we might add queue to these to further describe the behavior. so queueCurrentJob and queueNextJob or something like that. It feels to me like all Schedulers "queue", in some way, so that might be redundant. But I'm just one person, and I appreciate other opinions.

[benlesh]

How about:

RxJS 4	RxJS 5 Current	RxJS 5 Proposed
immediate	undefined	undefined or none
currentThread	immediate	queue
default	nextTick	job

[trxcllnt]

@Blesh I'm lukewarm on the job name, as it seems too generic (what's a job? when does it run? why?)

I'm inclined to name schedulers after the method in which they schedule:

Scheduler.immediate (same as RxJS 4, but iterative instead of recursive)
Scheduler.processQueue (flushes trampoline and blocks current event loop)
Scheduler.timeout (uses setTimeout/Interval)
Scheduler.eventLoop (uses setImmediate)
Scheduler.animationFrame (uses reqAnimFrame)

[staltz]

I liked currentJob/nextJob but I also liked what Paul suggested. At least we got rid of asap :)

[benlesh]

Scheduler.timeout (uses setTimeout/Interval)
Scheduler.eventLoop (uses setImmediate)

Still ambiguous: both timeout and eventLoop indeed schedule on the event loop.

[benlesh]

HAHA... soft reason that "job" is out: Try googling ECMAScript Job or JavaScript Job.

Yeah... no.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.