Re: GWT and concurrency

On Sep 17, 2:17 pm, Johannes Lehmann
<johannes.lehma...@googlemail.com> wrote:
> Hi,
>
> here is something that has been puzzeling me (and that may just be
> because I have misunderstood something trivial): I have read that
> JavaScript interpreters are usually single threaded. A page on
> supported language features seems to imply that for this reason, GWT
> doesn't not honor the synchronized keyword and does not provide any
> other locking mechanisms. Also of course you can't create more threads
> as you would in a normal Java application.
>
> Not that I would want to do that but what I'm wondering is when the
> Callbacks of AJAX calls are served. If they are served right away that
> would be like introducing another thread and would in some cases
> introduce the need for mutexes.
>
> Here is a concrete example: I have a call that, say, fetches a String
> Foo. Foo is needed at a few places in my program, so I write a Proxy
> method that will cache Foo so it is only fetched once. So on a call of
> that method it will check if Foo is in the cache and if not make the
> AJAX call (the method will also 'return' Foo via an AsyncCallback).
>
> This implementation will of course still fetch Foo multiple times,
> since the method will likely have been called more than once before
> the AJAX call returns and can cache the value of Foo. So what I would
> like to do is for my Proxy method, to store a list of requests for
> example like so:
>
> private List<AsyncCallback<String>> callbacks = new ...;
> private String foo;
>
> public FooProxy {
>   MyServiceAsync.getFoo(new AsyncCallback() {
>     /* On Success, cache the value in foo and notify all callbacks */
>   });
>
> }
>
> public void getFoo(AsyncCallback<String> callback) {
>   if(foo != null) callback.onSuccess(foo);
>   else callbacks.add(callback);
>
> }
>
> But if the callback from MyServiceAsync.getFoo can interrupt a call to
> getFoo at any time, this is clearly not 'thread safe'. However without
> any language support, I don't think it can be made so...
>
> Am I making any false assumptions here? Is there any other obvious way
> of achieving the desired effect?

JavaScript, in browsers, runs in the "UI thread" or "event-dispatching
thread". Whenever something happens (user clicks an element, timer
fires, XMLHttpRequest response arrives, image loads, etc.) it's posted
to the event queue. The UI thread continuously polls the event queue
for things to do and executes them right away. That's actually a
pretty standard behavior (I couldn't name a single GUI environment/
toolkit that doesn't revolve around an event loop).

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.