Received: by 10.115.102.39 with SMTP id e39mr1075854wam.22.1256079884086;
        Tue, 20 Oct 2009 16:04:44 -0700 (PDT)
Received: by 10.115.102.39 with SMTP id e39mr1075853wam.22.1256079884058;
        Tue, 20 Oct 2009 16:04:44 -0700 (PDT)
Return-Path: <smpar...@smparkes.net>
Received: from genericinfra.net (209-128-123-016.bayarea.net [209.128.123.16])
        by gmr-mx.google.com with ESMTP id 25si1001991pzk.3.2009.10.20.16.04.43;
        Tue, 20 Oct 2009 16:04:43 -0700 (PDT)
Received-SPF: pass (google.com: domain of smpar...@smparkes.net designates 209.128.123.16 as permitted sender) client-ip=209.128.123.16;
Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of smpar...@smparkes.net designates 209.128.123.16 as permitted sender) smtp.mail=smpar...@smparkes.net
Received: from [10.254.1.47] (paloalto.esseff.org [198.144.201.51])
	by genericinfra.net (Postfix) with ESMTP id 0CDFA2F2C3A
	for <envjs@googlegroups.com>; Tue, 20 Oct 2009 15:52:03 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
Mime-Version: 1.0 (Apple Message framework v1076)
Subject: Re: [env-js] Re: new timer implementation implications ...
From: Steven Parkes <smpar...@smparkes.net>
In-Reply-To: <b99491f30910201530i17233f95mcb4cde31f8bd3821@mail.gmail.com>
Date: Tue, 20 Oct 2009 16:04:12 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <7BDA9A94-C25C-4323-8302-0EC7BE1CE0AD@smparkes.net>
References: <0726585D-9924-4535-A12F-52D9DDE35E86@smparkes.net> <b99491f30910191504g7597b233pf74925870a845195@mail.gmail.com> <6198A3B4-BAA1-4F90-B46E-88FFC048CBEE@smparkes.net> <b99491f30910201456n34cbea1bs76c9c0fd41c06b1@mail.gmail.com> <428C8DE8-61FD-4F29-8E48-81999567051A@smparkes.net> <b99491f30910201530i17233f95mcb4cde31f8bd3821@mail.gmail.com>
To: "envjs@googlegroups.com" <envjs@googlegroups.com>
X-Mailer: Apple Mail (2.1076)


On Oct 20, 2009, at Oct 20,3:30 PM , chris thatcher wrote:

> var run = sync(function(){ //while happening only thing in this timer
>     //$env.debug("running timed function");
>     setTimeout(fn, 10);
> });

Actually, this isn't quite what you want to do either. First, you  
don't need the sync. It's only protecting the setTimeout call and  
that's already thread-safe.

But moreover, you've launched a thread to queue a callback ... which  
only actually get run on the main thread. Callbacks only happen on the  
main thread.

All you really need to do in this case is just run the target fn on a  
thread, which under rhino is as easy as spawn(fn). There's no sync'ing  
in starting the thread, only in communicating back to the main thread.  
That callback shouldn't touch anything else the main thread (or any  
other XHR threads) can see and those other threads shouldn't change  
anything its looking at. All it needs to do to communicate back to the  
main thread is, for example, do a setTimeout(cb,0) of user callbacks  
(like onreadystatechange) to get them queued cleanly on the main  
thread. It's a somewhat restrictive model, but works perfectly for  
something like XHR.

I'm not sure how careful one has to be. For example, can the async  
thread update the readystate in its thread, or should it use a  
callback to do that? To be clean, I'd use a callback, since I don't  
know what's atomic in JS and what's not (and it probably varies by  
interpreter). Actually, I can probably write a test to see what  
browsers do in that regard. I wouldn't be surprised if they update it  
on fly.

The only part I haven't worked out is fixing the wait loop. If the  
only thing going on is an XHR request, the wait loop wants to wait.  
But I'd rather it wait forever, rather than waking periodically the  
way it does now. But to do that, the XHR thread has to have a way to  
make the event loop end it's sleep early. That's too hard, just can't  
be done without crossing over into Java land. I don't think Rhino  
exposes enough to do that (though I can look again).