From: Scott Sauyet on
pedz wrote:
> On Jun 14, 9:24 pm, Scott Sauyet <scott.sau...(a)gmail.com> wrote:
>> pedz wrote:
>>> On Jun 14, 8:29 am, Scott Sauyet <scott.sau...(a)gmail.com> wrote:
>>>> pedz wrote:
>> I think a thread-scheduling algorithm for Javascript would be
>> extremely tricky.  There is no real notion of suspending execution of
>> a function, only of scheduling the execution after a delay.  Your code
>> would essentially have to manage the stopping and starting of
>> functions internally.  It's not even clear to me what that would
>> mean.
>
> Right.  I can't actually do a context switch nor do I even want to.
> The higher level code would likely break.
>
> Remember what a program is -- all programs.  Its a sequence of
> instructions.  Some instructions modify the PC.  Some modify the
> state.  Thats it.  On top of that is pile tons of sugar to make it so
> that humans can program.
>
> In this new paradigm, the "instruction" is a single javascript
> function.  The program fragments are lists of these instructions.  The
> PC is an index into this list.  Any type of looping will be syntactic
> sugar to modify this PC.  The calls to create, as we called them,
> "Sequence local" variables is what saves and retrieves the state.

Okay, I seriously underestimated your ambition. You're talking about
more than a DSL even, essentially a new language to be implemented
atop Javascript.

> All of that I'm comfortable with.  I've been doing compilers and such
> for many years.  But to write a compiler, I need to talk to the chip
> designers (or read their books).  In this project I need to talk to
> the Javascript guys.
>
>>> The HTML5 spec defines that only one thread per <something> ...
>>> "similar browsing contexts" I think is the term.  But it also defines
>>> that a web worker will be at least a separate thread but can be a
>>> separate process. [ ... ]
>
>> Have you used any implementations of this?
>
> Yes.  That is what triggered this.  I'm writing (as a self-tutorial)
> what I guess is called a server-less web application.  Its just a pile
> of HTML and javascript.  I have a "loader" and a "loader_worker" with
> the loader_worker being in a web worker.  The loader and loader_worker
> talk back and forth via the message facility.  It is asynchronous as
> you might expect.
>
> The original test rig using JSpec called the loader and then checked
> to see if the load failed (it was a bad request to test the error
> path) and the check was / is being done before the loader_worker would
> communicate back to the loader that the request failed.
>
> That doesn't really prove it is two separate threads I suppose but it
> definitely appears as if it is.

It most likely is. It's just that the HTML5 spec is still-evolving,
and I don't know how well the Web Worker stuff has settled down, nor
how good the implementations are. I haven't had any need for them
yet.

>> Yes, QUnit is similar, and any asynchronous testing toolkit probably
>> offers analogous capabilities.
>
> Any pointers to specific libraries in this area would help.

I don't have any links off-hand. But any test framework that allows
asynchronous calls presumably needs some similar facility.

Good luck,

-- Scott