Joachim Kuebart Reporter
	Description • 17 years ago

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 1.1.4322)
Build Identifier: JavaScript-C 1.7 pre-release 3 2007-04-01

A new API is proposed to allow an embedding application to suspend the
JavaScript interpreter from any native callback. This process is referred
to as "blocking" in the following. When a native callbacks blocks, the
JavaScript interpreter returns to the application immediately and without
losing the current execution state. The application can then perform any
processing of its own and may resume the interpreter at a later time. To
the JavaScript code, blocking native functions are indistinguishible from
normal ones.


Reproducible: Always

	Joachim Kuebart Reporter
	Comment 1 • 17 years ago

This is the second half of the patch originally submitted in bug 384412.

	Joachim Kuebart Reporter
	Comment 2 • 17 years ago

Note that the patch from comment 1 has to be applied on top of the patch in bug 384412 comment 34.

	Joachim Kuebart Reporter
	Comment 3 • 17 years ago

Updated the patch to today's CVS with the patch from bug 384412 comment 36 applied.

	Joachim Kuebart Reporter
	Comment 4 • 16 years ago

A new version of the patch that provides more functionality, in particular calculating hash values for blocked contexts and comparing blocked contexts with each other. This allows deciding whether two given blocked contexts represent identical "continuationns" or "futures," i.e. if executing either of them will run identical code.

This patch is based on trunk from 14 December 2007 and requires the patch from bug 384412 comment 44 to be applied first.

	Joachim Kuebart Reporter
	Comment 5 • 14 years ago

This patch contains a new class, Continuation, which is intended to work like Rhino's. An example Coroutine.js implementation is also included.

Due to the implementation of interpreter unwinding, Continuations are restricted in where they can be used, for example it is not possible to return from or restart property getters or setters using a Continuation.

	Brendan Eich [:brendan]
	Comment 6 • 14 years ago

Hi Joachim, good to hear from you. Couple of comments:

* We're less eager to take extensions that aren't going to be "Harmonious" in Ecma TC39, and call/cc is one such extension. The most we expect (knock on wood) are shallow continuations of the JS1.7 generators kind, based on Python 2.5. Is your patch for fun, or is PTC using it?

* Adding anything like call/cc is hard enough given the interpreter and native methods, getters/setters, debugger API. Add in trace- and method-JITs and it is quite a bit of work. Ignoring the first point about non-standardizability, is it worth it compared to using generators?

Cc'ing Dave Herman who is spec'ing generators for ECMA-262's next edition, and Igor Bukanov, who reworked the Cocoon-originated Rhino Continuation object code.

/be

	Joachim Kuebart Reporter
	Comment 7 • 14 years ago

Hi Brendan,

thank you for your comments

(In reply to comment #6)
> * We're less eager to take extensions that aren't going to be "Harmonious" in
> Ecma TC39, and call/cc is one such extension. The most we expect (knock on
> wood) are shallow continuations of the JS1.7 generators kind, based on Python
> 2.5. Is your patch for fun, or is PTC using it?

Yes, we are actually using this. :) We have retrofitted the JS interpreter to an existing application and many of our native methods need to unwind the JS interpreter to do some processing in the host application and then resume JS at a later time. Using generators would severely limit user's scripts to just one stack frame and force users to use "yield" explicitly, which would prevent a "natural" coding style.

The original (now obsolete) patch in this bug provided a JS_CloneContext call that duplicated the JS stack currently running in that context. This feature wasn't exposed to the language and only usable by the host application.

However, JSContext cloning became too expensive due to the way that the stack memory is now allocated in recent versions (we're unwinding the interpreter hundreds of times per second). So now I just store the stack frames and push them back onto the context when the continuation is called. At that point, it seemed straightforward and useful to expose this as a Continuation class to the language. We're still hiding the interpreter unwinding from the users, so any other way to unwind the interpreter from inside native calls would also be fine for us.

> * Adding anything like call/cc is hard enough given the interpreter and native
> methods, getters/setters, debugger API. Add in trace- and method-JITs and it is
> quite a bit of work. Ignoring the first point about non-standardizability, is
> it worth it compared to using generators?

The trace-JITting seems to be working along nicely with my stackless changes, however I can't claim the same for JägerMonkey. That's the reason I've only implemented this for gecko-1.9.2 at this point. I had made some progress at keeping up with /tracemonkey development, but at some point it was simply changing too fundamentally for me to keep up...

Having a "mostly stackless" interpreter as in bug 384412 would already be a great help even if JSContext cloning or Continuations aren't considered generally useful to be included. But I realise that it's a fairly big change to the VM for not much benefit if "deep continuations" don't become part of the language. I do believe it's very useful for an embedding to be able to leave the interpreter from inside a native method and resume it later.

Joachim

	André Bargull [:anba]
	Comment 8 • 7 years ago

New features to JavaScript should now be proposed to TC39 [1] before being implemented in SpiderMonkey, therefore closing as Invalid.

[1] https://github.com/tc39/proposals/blob/master/CONTRIBUTING.md