On Fri, Aug 15, 2008 at 7:54 AM, Maksim Orlovich <[EMAIL PROTECTED]> wrote:
> It's actually a lot worse in this case, since the ECMAScript runtime must
> be able to enforce the sandbox properly even in face of incorrectly
> threaded programs.
> In particular, if two threads are accessing propertie
On Thu, Aug 14, 2008 at 10:06 PM, Shannon <[EMAIL PROTECTED]> wrote:
> On second thoughts I withdraw these claims. I don't have the statistics to
> know one way or the other why "portable threads" are more prevalent than
> "share nothing" ones. There may be many reasons but latencies probably isn'
Shannon wrote:
Think about the kind of applications that use parallel "compute nodes"
and you'll realise that 98% don't exist outside of academia and
laboratories due to synchronisation, network latencies and other
issues that implementing Javascript workers won't solve. More
importantly thoug
Aaron Boodman wrote:
There are a bunch of examples that Ian has kindly written at the very
top of the document. What was unhelpful about them?
After reading this I went back to look for them. What happened
originally was that I followed one of the links and seeing only a single
line of tex
PM
To: Kristof Zelechovski
Cc: 'Jonas Sicking'; 'WHAT working group'
Subject: Re: [whatwg] WebWorkers vs. Threads
Kristof Zelechovski wrote:
> A background task invoked by setTimeout has to be split to small chunks;
> _yielding_ occurs when each chunk ends (having called setT
On Thu, Aug 14, 2008 at 12:23 AM, Kristof Zelechovski
<[EMAIL PROTECTED]> wrote:
> Sorry, I do not get it. Where does the value of (la) make it into
> (e.message)?
Sorry, I forgot a line:
> // main.js
> var la = 0; // what is with this variable name?
> var worker = createWorker("worker.js");
> w
Subject: Re: [whatwg] WebWorkers vs. Threads
You're right that if you try to use workers like threads, you end up
with threads. A more message-passing style implementation is easier.
In particular you would not want to allow the worker to 'get' and
'set' individual variab
On Wed, Aug 13, 2008 at 11:50 AM, Shannon <[EMAIL PROTECTED]> wrote:
> The WebWorkers implementation (scary! hide your children!!):
>
> --- worker.js ---
> updateGlobalLa = function (e) {
> var localLa = someLongRunningFunction( e );
> workerGlobalScope.port.postMessage("set la = "+ localLa);
> }
Kristof Zelechovski wrote:
A background task invoked by setTimeout has to be split to small chunks;
_yielding_ occurs when each chunk ends (having called setTimeout to execute
the next chunk). It is very hard to code in this way; you have to maintain
an explicit stack and create an exit/entry po
W liście Shannon z dnia środa 13 sierpnia 2008:
> He wasn't against WebWorkers, he was, as you say, against full
> threading (with all the mutexes and locks etc... exposed to the JS
> author). I can't find the reference site but it doesn't really matter
> except from the point of view that many p
group
Subject: Re: [whatwg] WebWorkers vs. Threads
Jonas Sicking wrote:
> What you describe above is also known as cooperative multithreading.
> I.e. each "thread" has to manually stop itself regularly and give
> control to the other threads, and eventually they must do the same
Jonas Sicking wrote:
Shannon wrote:
I've been following the WebWorkers discussion for some time trying to
make sense of the problems it is trying to solve. I am starting to
come to the conclusion that it provides little not already provided by:
setTimeout(mainThreadFunc,1)
setTimeout(workThre
On Tue, Aug 12, 2008 at 2:51 AM, Shannon <[EMAIL PROTECTED]> wrote:
> I thought Lua had an implementation of automated locking to use as a
> reference but since it doesn't I have nothing more to offer on the subject.
> Without knowing the internals of existing JS implementations I have no idea
> wh
--http://lua-users.org/wiki/CoroutinesTutorial
Is this description incorrect? It seems at odds with what you said
about Lua coroutines getting an OS thread (if one is available).
The description you quoted from lua-users.org is correct. The primary
implementation of Lua is 100% portable I
On 11 Aug 2008, at 18:43, Aaron Boodman wrote:
On Sun, Aug 10, 2008 at 5:54 PM, Shannon <[EMAIL PROTECTED]> wrote:
* each coroutine gets a real OS thread (if available).
Coroutines in Lua are not operating system threads or processes.
Coroutines are blocks of Lua code which are created with
Count'
than 'gTrans.count'.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Shannon
Sent: Monday, August 11, 2008 2:54 AM
To: Jonas Sicking
Cc: WHAT working group
Subject: Re: [whatwg] WebWorkers vs. Threads
Maybe I misunderstand th
On Sun, Aug 10, 2008 at 5:54 PM, Shannon <[EMAIL PROTECTED]> wrote:
> * each coroutine gets a real OS thread (if available).
Coroutines in Lua are not operating system threads or processes.
Coroutines are blocks of Lua code which are created within Lua, and
have their own flow of control like thr
Shannon wrote:
Jonas Sicking wrote:
Shannon wrote:
I've been following the WebWorkers discussion for some time trying to
make sense of the problems it is trying to solve. I am starting to
come to the conclusion that it provides little not already provided by:
setTimeout(mainThreadFunc,1)
set
Jonas Sicking wrote:
Shannon wrote:
I've been following the WebWorkers discussion for some time trying to
make sense of the problems it is trying to solve. I am starting to
come to the conclusion that it provides little not already provided by:
setTimeout(mainThreadFunc,1)
setTimeout(workThre
Shannon wrote:
I've been following the WebWorkers discussion for some time trying to
make sense of the problems it is trying to solve. I am starting to come
to the conclusion that it provides little not already provided by:
setTimeout(mainThreadFunc,1)
setTimeout(workThreadFunc,2)
setTimeout(w
I've been following the WebWorkers discussion for some time trying to
make sense of the problems it is trying to solve. I am starting to come
to the conclusion that it provides little not already provided by:
setTimeout(mainThreadFunc,1)
setTimeout(workThreadFunc,2)
setTimeout(workThreadFunc,2)
21 matches
Mail list logo
