concurrency issues, which the synchronized keyword was designed to
address. Without any language support such as semaphores or mutexes
and without any guarantees regarding preemption, how could I solve a
problem such as the above?
Thanks,
Johannes
On Sep 17, 3:51 pm, Thomas Broyer <t.bro...@gmail.com> wrote:
> 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.
No comments:
Post a Comment