Re: Sync API for workers
Let me introduce the first sketch of a variant. The general idea is to
add a |postSyncMessage|
We extend DedicatedWorkerGlobalScope and MessageEvent as follows:
interface DedicatedWorkerGlobalScope : WorkerGlobalScope {
void postMessage(any message, optional sequenceTransferable transfer);
any postSyncMessage(any message, optional sequenceTransferable
transfer);
};
interface SyncMessageEvent : MessageEvent {
void reply(optional any message, optional sequenceTransferable
transfer);
};
The behavior of |postSyncMessage| is the following:
1. the sender worker sleeps and does not handle any |postMessage|
messages until it is awakened;
2. instead of the usual |MessageEvent|, the target's |onmessage|
receives as argument a |SyncMessageEvent| (call it |s|);
3. if |s.reply(x)| is called, the sender's |postSyncMessage| method
returns a copy of |x|, obtained with the usual algorithm;
5. if |s.reply()| has not called by the time the worker is either
garbage-collected or |terminate()| is called on its |MessagePort|, the
worker is killed as usual.
I have not attempted to detail the inner workings of the underlying
MessagePort, but I suspect that this is close to Jonas Sicking's proposal.
Cheers,
David
Re: Sync API for workers
On 10/13/13 4:21 PM, James Greene wrote: a) is necessary, but for b) it is sufficient for the sync thread to be able to sleep until a condition/mutex/... is lifted In other words, your clarification is completely true but my initial statement was written with regard to client-side JavaScript, which cannot sleep. As such, I believe my original assertions are still correct with regard to writing a sync wrapper in JS. My apologies, I had obviously misunderstood your initial statement. I was thinking of an extension of the Worker API and how to implement it at little CPU/battery clost. Cheers, David -- David Rajchenbach-Teller, PhD Performance Team, Mozilla
Re: Sync API for workers
- Original Message - From: David Bruant bruan...@gmail.com To: Jonas Sicking jo...@sicking.cc Cc: public-webapps public-webapps@w3.org, aza...@mozilla.com Sent: Sunday, October 13, 2013 1:36:22 PM Subject: Re: Sync API for workers * You could solve the use case of compile-to-JS for code that uses sync APIs using yield. However it requires changing all functions into generators, and all function calls into yield* statements. all? as is all function in the application? that sounds like a too violent constraint, especially if a small proportion of the code uses sync functions. Maybe only the functions that may call a sync function need to be changed to generators... oh... hmm... I don't know. Taking the liberty to cc Alon Zakai to ask for his expert opinion on this topics. Not sure about all the context here. In general, the idea of using yield or CPS to handle synchronous code has come up in emscripten, but no one has done work to implement it, so we don't have a concrete answer for how practical it would be. My guess however is that it would be not very practical, because large codebases can have sync code anywhere, and relying on static analysis to simplify that so it is mostly not a factor is very optimistic. CPS all the time would likely be too slow; yield all the time I am less clear on because I am not sure the implementations are mature enough to benchmark yet (and no implementation at all in IE and Safari last I heard) - we would need to ask JS engine devs on that. - Alon
Re: Sync API for workers
On Mon, Oct 14, 2013 at 2:33 AM, David Rajchenbach-Teller
dtel...@mozilla.com wrote:
Let me introduce the first sketch of a variant. The general idea is to
add a |postSyncMessage|
We extend DedicatedWorkerGlobalScope and MessageEvent as follows:
interface DedicatedWorkerGlobalScope : WorkerGlobalScope {
void postMessage(any message, optional sequenceTransferable transfer);
any postSyncMessage(any message, optional sequenceTransferable
transfer);
};
interface SyncMessageEvent : MessageEvent {
void reply(optional any message, optional sequenceTransferable
transfer);
};
This API was suggested by Olli way up in this thread. It has a few downsides:
1. It only allows a single synchronous message channel. That means
that if you have several libraries that all need synchronous
communication with the parent they have to coordinate on some way to
distinguish each others messages. The fact that Gecko hasn't had
MessageChannel support has resulted in the same problem for
asynchronous communication and that has been a big headache for
developers.
2. It doesn't support streaming return values. I.e. you can't send
multiple return values from a single postSyncMessage call.
3. It doesn't allow direct synchronous communication between a worker
and the workers grand parent. Everything single message has to be
individually routed through the parent.
4. What happens if you have multiple eventlisteners in the parent and
several of them call .reply()?
I wouldn't say that all of these are killer issues. I do think the
first one is though. And the other three are clearly downsides.
All in all I think the added complexity in the later proposal is worth it.
/ Jonas
Re: Sync API for workers
You snipped the comment about waitForMessage(). I think it should return an Event, as if the message had been received from onmessage, not just the received data. On Sun, Oct 13, 2013 at 10:37 PM, Jonas Sicking jo...@sicking.cc wrote: This is certainly an improvement over the previous proposal. However given that synchronous APIs of any type are quite controversial, I'd rather stick to a basic approach for now. There's nothing controversial about synchronous APIs in workers. Doing work synchronously is the whole point. The nice thing about your proposal is that it's strictly additive, so it's something we can add later if there's agreement that the problems it aims to solve are problems that need solving, and there's agreement that the proposal is the right way to solve them. This will cause people to learn to structure their workers poorly, and to create worker libraries based on that structure, with extra message relaying infrastructure to work around this, and pollute people's still-immature understanding of message ports. We should do it right in the first place. On Mon, Oct 14, 2013 at 4:33 AM, David Rajchenbach-Teller dtel...@mozilla.com wrote: Let me introduce the first sketch of a variant. The general idea is to add a |postSyncMessage| (I'm not sure what problems with the existing proposals this is trying to solve.) -- Glenn Maynard
Re: Sync API for workers
This meant to be a more limited and well-behaved variant. However, as pointed out by Jonas, a very similar proposal has been submitted and discussed long before I joined this list. So, please disregard my proposal, it is an artifact of me not searching the archives well enough. Best regards, David On 10/14/13 4:14 PM, Glenn Maynard wrote: On Mon, Oct 14, 2013 at 4:33 AM, David Rajchenbach-Teller dtel...@mozilla.com mailto:dtel...@mozilla.com wrote: Let me introduce the first sketch of a variant. The general idea is to add a |postSyncMessage| (I'm not sure what problems with the existing proposals this is trying to solve.) -- Glenn Maynard -- David Rajchenbach-Teller, PhD Performance Team, Mozilla
Re: Sync API for workers
Could we change the method name under discussion to `postMessageSync`
instead of `postSyncMessage`? I know they're not grammatically equivalent
but I've always found the *Sync suffixes used on pertinent Node.js APIs to
be much more intuitive than trying to guess which position within a string
of words it should take.
Not sure on prior art within the web platform.
On Oct 14, 2013 4:59 AM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Oct 14, 2013 at 2:33 AM, David Rajchenbach-Teller
dtel...@mozilla.com wrote:
Let me introduce the first sketch of a variant. The general idea is to
add a |postSyncMessage|
We extend DedicatedWorkerGlobalScope and MessageEvent as follows:
interface DedicatedWorkerGlobalScope : WorkerGlobalScope {
void postMessage(any message, optional sequenceTransferable
transfer);
any postSyncMessage(any message, optional sequenceTransferable
transfer);
};
interface SyncMessageEvent : MessageEvent {
void reply(optional any message, optional sequenceTransferable
transfer);
};
This API was suggested by Olli way up in this thread. It has a few
downsides:
1. It only allows a single synchronous message channel. That means
that if you have several libraries that all need synchronous
communication with the parent they have to coordinate on some way to
distinguish each others messages. The fact that Gecko hasn't had
MessageChannel support has resulted in the same problem for
asynchronous communication and that has been a big headache for
developers.
2. It doesn't support streaming return values. I.e. you can't send
multiple return values from a single postSyncMessage call.
3. It doesn't allow direct synchronous communication between a worker
and the workers grand parent. Everything single message has to be
individually routed through the parent.
4. What happens if you have multiple eventlisteners in the parent and
several of them call .reply()?
I wouldn't say that all of these are killer issues. I do think the
first one is though. And the other three are clearly downsides.
All in all I think the added complexity in the later proposal is worth it.
/ Jonas
CfC: publish LCWD of Custom Elements; deadline October 21
Dimitri and I did not notice any concerns to the request for pre-LC comments for Custom Elements [pre-LC] so this is a CfC to publish a LCWD of this spec using the following ED as the basis: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html This CfC satisfies the group's requirement to record the group's decision to request advancement for this LCWD. Note the Process Document states the following regarding the significance/meaning of a LCWD: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#last-call Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. ]] Currently, there are 10 open bugs for this spec and they have all been marked as Resolved/Later [Bugs]. The proposed review period for this LC is 4 weeks. If anyone thinks the review period should be longer, please speak up. If you have any comments or concerns about this CfC, please send them to public-webapps@w3.org by October 21 at the latest. Positive response is preferred and encouraged and silence will be considered as agreement with the proposal. Assuming this CfC passes, if there are any specific groups (e.g. HTMLWG, TAG, I18N, WAI, Privacy IG, Security IG, etc.) we should ask to review the LCWD, please let me know. -Thanks, AB [pre-LC] http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0080.html [Bugs] http://bit.ly/GIZamj
Re: [gamepad] Seeking status and plans
Hi All, The Gamepad API was briefly discussed at the LXJS conference. See: http://www.youtube.com/watch?v=ekvaKmVfjtct=5m30s It seems at least one developer is very unhappy with it. Have we received any other feedback from developers about it? Has any effort been made to reach out to other developers to get feedback? Kind regards, Marcos -- Marcos Caceres On Thursday, October 10, 2013 at 7:12 PM, Ted Mielczarek wrote: On 10/2/2013 12:31 PM, Arthur Barstow wrote: Hi Ted, Scott, If any of the data for the Gamepad spec in [PubStatus] is not accurate, please provide corrections. Also, if you have any new information re your plans for the spec - last published 29-May-2012 - or the spec's status with respect to being feature complete, implementation status, etc., please let us know. -Thanks, ArtB [PubStatus] http://www.w3.org/2008/webapps/wiki/PubStatus Hi Art, Thanks for the nudge! My work on the spec (and the Firefox implementation) fell by the wayside for many months, but I found some time to work on my implementation recently. We (Mozilla) are shipping a very-close-to-spec implementation in Nightly builds, and it's available behind a preference in our current release (Firefox 24). I'd actually like to ship our implementation in release soon, I just have a few minor implementation bugs (with significant impact) to fix as well as one possible breaking spec change[1]. With those in order I'd be pretty happy to ship. We'd be shipping unprefixed, as is our new policy. It's my understanding that Google has been shipping a prefixed implementation that's also pretty close to the spec for some time now, but that Scott suffers from the same Gamepad is not really my full-time job problem that I do. He'd be more equipped to talk about this than I am, certainly. In terms of feature-completeness I think the spec is basically done. Aside from that one breaking change I'd like to make I don't think there's anything else we want to address right now that couldn't be done in a future release of the spec. We've wanted to keep the scope small from the beginning and I think we did okay. It definitely needs some more work (mostly polishing of the text, fixing the existing bugs), but we could certainly get out a new WD with the most recent text. -Ted 1. https://www.w3.org/Bugs/Public/show_bug.cgi?id=21388
