On Feb 14, 2:46 am, Boris Zbarsky wrote:
> On 2/13/13 7:36 PM, Simon Kornblith wrote:
>
> > Don't workers have access to XMLHttpRequest?
>
> That's implemented by sending messages to the main thread and doing the
> XHR from there, so no messages means no XHR.
>
> -Boris
There's a difference betwe
On 2/13/13 7:36 PM, Simon Kornblith wrote:
Don't workers have access to XMLHttpRequest?
That's implemented by sending messages to the main thread and doing the
XHR from there, so no messages means no XHR.
-Boris
___
dev-platform mailing list
dev-p
On Feb 13, 5:25 pm, Benjamin Smedberg wrote:
> On 2/13/2013 4:28 PM, Kyle Huey wrote:
>
>
>
>
>
>
>
> > On Wed, Feb 13, 2013 at 9:20 PM, Benjamin Smedberg
> > wrote:
>
> >> On 2/13/2013 1:39 PM, Kyle Huey wrote:
>
> >>> On Wed, Feb 13, 2013 at 6:35 PM, Brian Smith wrote:
>
> >>> At what point
On 2/13/2013 4:28 PM, Kyle Huey wrote:
On Wed, Feb 13, 2013 at 9:20 PM, Benjamin Smedberg wrote:
On 2/13/2013 1:39 PM, Kyle Huey wrote:
On Wed, Feb 13, 2013 at 6:35 PM, Brian Smith wrote:
At what point during XPCOM shutdown are workers destroyed?
xpcom-shutdown-threads
What workers ar
On Wed, Feb 13, 2013 at 9:20 PM, Benjamin Smedberg wrote:
> On 2/13/2013 1:39 PM, Kyle Huey wrote:
>
>> On Wed, Feb 13, 2013 at 6:35 PM, Brian Smith wrote:
>>
>> At what point during XPCOM shutdown are workers destroyed?
>>>
>>> xpcom-shutdown-threads
>>
> What workers are these? Do workers out
On 2/13/2013 1:39 PM, Kyle Huey wrote:
On Wed, Feb 13, 2013 at 6:35 PM, Brian Smith wrote:
At what point during XPCOM shutdown are workers destroyed?
xpcom-shutdown-threads
What workers are these? Do workers outlast the page that loaded them?
The entire DOM should be torn down at or before
Kyle Huey wrote:
> Brian Smith < bsm...@mozilla.com > wrote:
>
> At what point during XPCOM shutdown are workers destroyed?
>
> xpcom-shutdown-threads
NSS gets shut down way before then, because it can write to the profile. Same
with Necko.
Cheers,
Brian
___
On Wed, Feb 13, 2013 at 6:35 PM, Brian Smith wrote:
> At what point during XPCOM shutdown are workers destroyed?
>
xpcom-shutdown-threads
- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platfo
Kyle Huey wrote:
>1. Dealing with the different ownership model on worker threads
>(no cycle collector, all owning references go through JS).
>2. Dealing with things that are not available off the main thread
>(no necko, no gfx APIs, etc).
FWIW, I think the networking team has a go
This is a report of a possible bug related to this.
> It also has the serious disadvantage that
>mistakes result in exploitable use-after-frees, rather than unexploitable
>leaks. It also causes various problems with the WebIDL binding
>codegenerator in its current incarnation.
I just ran across
On Fri, 8 Feb 2013, Robert O'Callahan wrote:
>
> We'd definitely implement it with the goal that the worker can get a
> canvas update onto the screen even if the HTML event loop is blocked by
> a long-running task. That's needed to ensure that games can get a stable
> frame rate.
>
> If it turn
We'd definitely implement it with the goal that the worker can get a canvas
update onto the screen even if the HTML event loop is blocked by a
long-running task. That's needed to ensure that games can get a stable
frame rate.
If it turns out that violates the spec (I haven't looked), then we'll lo
On Thu, 7 Feb 2013, David Rajchenbach-Teller wrote:
>
> I am curious: does this mean an actual user-visible present on
> a webpage or "just" off-main screen canvas?
The way it's specced in the HTML spec right now it can involve pushing
bits to the screen, but it's modelled in such a way that re
I am curious: does this mean an actual user-visible present on
a webpage or "just" off-main screen canvas?
Cheers,
David
On 2/7/13 12:27 AM, Robert O'Callahan wrote:
> We're going to want to add worker bindings for canvas (both 2D and WebGL).
> Over time I expect we'll want worker versions of a
- Original Message -
> Has anyone considered whether the cost of TLS could become a problem?
> It seems like it is a bit of a problem for SPS. Seems like a fixable
> problem though, especially for code that can statically know whether it's on
> or off the main thread.
In addition to what
On Wed, Feb 6, 2013 at 11:51 PM, Robert O'Callahan wrote:
> This is great news!
>
>
> On Thu, Feb 7, 2013 at 12:32 PM, Kyle Huey wrote:
>
>> *The plan*
>>
>> Therefore we've decided to discard the worker model in favor of a cycle
>> collected model like we have on the main thread. Our plan is to
This is great news!
On Thu, Feb 7, 2013 at 12:32 PM, Kyle Huey wrote:
> *The plan*
>
> Therefore we've decided to discard the worker model in favor of a cycle
> collected model like we have on the main thread. Our plan is to do the
> following:
>
>1. Port the cycle collector to non-main-thr
We talked about this at the DOM work week a day or two ago. Kyle has a patch
in progress. There are some other things that have to be done for it to work
that I don't recall.
Andrew
- Original Message -
> We're going to want to add worker bindings for canvas (both 2D and
> WebGL).
> O
I'll just copy/paste the email I had in my drafts folder.
On Wed, Feb 6, 2013 at 11:27 PM, Robert O'Callahan wrote:
> We're going to want to add worker bindings for canvas (both 2D and WebGL).
> Over time I expect we'll want worker versions of almost every popular DOM
> API that doesn't actually
As a matter of fact, there was just a decision yesterday here at the London
DOM work week to implement a cycle collector for workers. Kyle is doing it,
and can probably fill in any necessary details. He says it "shouldn't be
that hard."
bholley
On Wed, Feb 6, 2013 at 11:27 PM, Robert O'Callahan w
We're going to want to add worker bindings for canvas (both 2D and WebGL).
Over time I expect we'll want worker versions of almost every popular DOM
API that doesn't actually require content/layout. We need to be able to
share code between worker and main-thread implementations as much as
possible.
21 matches
Mail list logo
