Closed benlesh closed 8 years ago
I see no objections to this...
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.
Trampoline sounds the best IMO.
+1 for trampoline
and 'currentThread didn't make sense ' both. (intrigued into 'jenga' for sec..)
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.
@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
@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 fashionScheduler.async
for slower mechanisms such as setTimeout
etcScheduler.immedate
once again for immediate schedulingScheduler.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.
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.
@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.
From my point of view the only kind of scheduling that makes sense is "job queuing" (called microtask queue elsewhere). : \
Therefore I don't see the point in all of these different (and confusing) names.
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. :)
@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 ... well PR that thing! 😝
@blesh still needs tests ;-)
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?
... the ideal being no name change, or no conflicting names (immediate
is different in RxJS 4 and 5 currently)
@blesh I like these names
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.
Those names looks good to me.
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.
I just don't like
asap
In the ES spec world, we call these things "jobs" and we have a "job queue".
Scheduler.job
? Is job
common enough vernacular?
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? |
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.
How about:
RxJS 4 | RxJS 5 Current | RxJS 5 Proposed |
---|---|---|
immediate | undefined | undefined or none |
currentThread | immediate | queue |
default | nextTick | job |
@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)
I liked currentJob
/nextJob
but I also liked what Paul suggested. At least we got rid of asap
:)
Scheduler.timeout (uses setTimeout/Interval) Scheduler.eventLoop (uses setImmediate)
Still ambiguous: both timeout and eventLoop indeed schedule on the event loop.
HAHA... soft reason that "job" is out: Try googling ECMAScript Job or JavaScript Job.
Yeah... no.
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.
Currently the trampoline scheduler is named
immediate
, and the microtask scheduler is namednextTick
. There is alsI propose that we rename
immediate
tosync
. I say this becauseimmediate
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 namedmicrotask
, because ultimately that's the goal. To schedule it as a microtask after the current frame but before things likesetTimeout
.... which brings me to another thing, we don't have a scheduler based off of
setTimeout
orrequestAnimationFrame
. 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.