Move event loop stuff to bottom for now

parent 6565c574
......@@ -270,40 +270,6 @@ Suspends the current thread for the given number of milliseconds. Fractional
milliseconds are supported up to nanosecond resolution, but accuracy depends
on the underlying C library implementation of `nanosleep`.
## Event Loop
Everyone else is using `libuv`. But libuv actually does *more* than I think
is actually necessary. And using it would means that `dukboot` would have exactly the same
bugs / vulnerabilities as all the other stuff out there. So why not be crazy
and try something different?
A lot of JS programmers are mystified by the Event Loop. This is largely because
its existance is *implicit*, and you can go for years writing JavaScript and
never even be aware of it. It is used via functions like `setImmediate()` and
`process.nextTick()` and `requestAnimationFrame()` and `requestIdleCallback()`
which are all poorly named\* and obscure what's really going on. Once you understand
it, it's extremely simple! It's a cooperative scheduler. Callbacks are put in a queue and
get executed in order for the most part. Some things, like animation frames in
the browser or I/O in node, get executed out-of-order to satisfy constraints:
animationFrame callbacks need to happen between window paint events for instance
and I/O callbacks cannot be called until the data they are asking for arrives.
But at its heart, it's just a handful of queues that the scheduler picks from.
So I figure... why not make that explicit? Why not literally represent the
queues as a JS arrays, so you can write your own scheduling logic? You can see
my initial fooling around with this idea in the `examples/time/` directory.
Conceptually, you would have one Duktape.Thread be the "scheduler" and have a
while loop that pops callbacks from the queue(s) and run them until the queue is
empty. The callbacks themselves, other Duktape Threads, or the C code will insert
new callbacks into the queues so the scheduler thread has stuff to execute.
\* except requestAnimationFrame, which actually does what the name suggests
### Queues.timers (name subject to change)
Right now this is the only queue. I'm storing it in the heap-stash. The code in
`examples/time/` shows you can actually pull off the whole event loop in JS without
using any C code. This may prove a totally awesome idea or a completely
terrible one; I don't know yet.
## ~~Module System~~ Sandbox
A wise man once said,
......@@ -350,7 +316,7 @@ an `imports` object as it initial argument, which looks something like this:
{
"main": [object Object],
"stdio": [object Object],
"threadpool": [object Object],
"thread": [object Object],
"netLib": [object Object],
...
}
......@@ -382,6 +348,40 @@ This is a pretty sweet library. It's a single C file, and does enough to make a
I would like to have some kind of suped up socket like zeromq or nanomsg built into dukboot, so that you can start building advanced network topologies right away without worrying about protocols. However, I can't get either of them to compile yet.
## Event Loop
Everyone else is using `libuv`. But libuv actually does *more* than I think
is actually necessary. And using it would means that `dukboot` would have exactly the same
bugs / vulnerabilities as all the other stuff out there. So why not be crazy
and try something different?
A lot of JS programmers are mystified by the Event Loop. This is largely because
its existance is *implicit*, and you can go for years writing JavaScript and
never even be aware of it. It is used via functions like `setImmediate()` and
`process.nextTick()` and `requestAnimationFrame()` and `requestIdleCallback()`
which are all poorly named\* and obscure what's really going on. Once you understand
it, it's extremely simple! It's a cooperative scheduler. Callbacks are put in a queue and
get executed in order for the most part. Some things, like animation frames in
the browser or I/O in node, get executed out-of-order to satisfy constraints:
animationFrame callbacks need to happen between window paint events for instance
and I/O callbacks cannot be called until the data they are asking for arrives.
But at its heart, it's just a handful of queues that the scheduler picks from.
So I figure... why not make that explicit? Why not literally represent the
queues as a JS arrays, so you can write your own scheduling logic? You can see
my initial fooling around with this idea in the `examples/time/` directory.
Conceptually, you would have one Duktape.Thread be the "scheduler" and have a
while loop that pops callbacks from the queue(s) and run them until the queue is
empty. The callbacks themselves, other Duktape Threads, or the C code will insert
new callbacks into the queues so the scheduler thread has stuff to execute.
\* except requestAnimationFrame, which actually does what the name suggests
### Queues.timers (name subject to change)
Right now this is the only queue. I'm storing it in the heap-stash. The code in
`examples/time/` shows you can actually pull off the whole event loop in JS without
using any C code. This may prove a totally awesome idea or a completely
terrible one; I don't know yet.
## Disk I/O
I'll provide access to files, but it will be with an interface more like `abstract-blob-store` than `fs`. Will also provide something like `abstract-chunk-store` for direct block level access.
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment