After some thought, I don't think putting it in IncrementalCommand and
execute with DeferredCommand help much here. Jeff, If I understand you
correctly, my execute method will look like this:
class Executor {
// declaration of list of commands
void execute() {
DeferredCommand.addCommand(new IncrementalCommand() {
boolean executing;
int currentIdx;
public boolean execute() {
if (executing) return true; // executor will keep looping
// it's my turn now
executing = true;
AsyncCommand cmd = commands.get(currentIdx);
cmd.execute(new AsyncCallback() {
public void onFailure(Throwable e) { onSuccess(null); }
public void onSuccess(Object o) {
executing = false;
++currentIdx;
}
}
// return point
}
}
The above method is actually still non-blocking. There's no guarantee that
my incremental command will finish executing before I reach //return point.
Did I miss anything?
On Thu, Aug 12, 2010 at 2:35 PM, Kevin Qiu <[email protected]> wrote:
> Thanks. That's helpful.
>
>
> On Thu, Aug 12, 2010 at 12:05 PM, Jeff Chimene <[email protected]> wrote:
>
>> On 08/12/2010 08:38 AM, salk31 wrote:
>> > Don't you have to count the async returning and then do yet another
>> > callback?
>> >
>> > So hook into the callback of all your commands and then when the last
>> > one is done do the callback?
>>
>> Extending salk31's logic:
>> Put your execute() inside a loop, inside an IncrementalCommand. Your
>> execute() routine implements a mutex. The loop terminates per salk31's
>> observation. The execute() routine sets the mutex before the async call,
>> and clears it in OnResponseReceived(), OnError(). The loop checks that
>> mutex and immediately returns to the IncrementalCommand if set. In FF
>> 3.6, I found it was too easy to overload the server (resulting in
>> response timeouts) w/o serializing the calls via a mutex. IOW, simply
>> allowing the brower's RPC queue to serialize (i.e. clear the execute()
>> queue as fast as possible) resulted in dropped calls.
>>
>> I believe the above will work w/ Java RPC.
>>
>> If there are many list elements, you might want a timer that controls a
>> "loading..." message.
>>
>> Also, you might want to evaluate at the Dictionary class to see if
>> that's a better fit for the problem you're trying to solve.
>>
>> >
>> > On Aug 12, 3:30 pm, Kevin Qiu <[email protected]> wrote:
>> >> I don't know if the title makes sense but working with gwt for about 2
>> >> years, I often find myself in the position to mix both asynchronous and
>> >> synchronous (blocking) apis. It's easy to transform a synchronous call
>> to
>> >> asynchronous, but the other way around is not immediately obvious to
>> me,
>> >> especially in the context of the single-threaded browser environment.
>> >>
>> >> Imagine I the following:
>> >>
>> >> abstract class GetList<T> {
>> >> abstract void execute(AsyncCallback<List<T>> callback);
>> >>
>> >> }
>> >>
>> >> class GetContactList extends GetList<Contact> {
>> >> void execute(AsyncCallback<List<Contact>> callback) { /*
>> implementation */
>> >>
>> >> }
>> >> }
>> >>
>> >> class GetAddressList extends GetList<Address> {
>> >> void execute(AsyncCallback<List<Address>> callback) { /*
>> implementation */
>> >>
>> >> }
>> >> }
>> >>
>> >> class GetPhoneList extends GetList<Phone> {
>> >> void execute(AsyncCallback<List<Phone>> callback) { /* implementation
>> */ }
>> >>
>> >> }
>> >>
>> >> now imagine I keep a list of GetList objects:
>> >> List<GetList> commands = Arrays.asList(new GetContactList(), new
>> >> GetAddressList(), new GetPhoneList());
>> >>
>> >> and I have an executor that executes these commands:
>> >>
>> >> class Executor {
>> >> List<? extends GetList<?>> commands;
>> >> Executor(List<? extends GetList<?>> commands) {
>> >> this.commands = commands;
>> >> }
>> >> void execute() {
>> >> // XXX:
>> >> }
>> >>
>> >> }
>> >>
>> >> Now, for whatever reason, I need my execute() method to be a blocking
>> call
>> >> (synchronous). It should terminate after all GetList calls are
>> returned. How
>> >> can I achieve this?
>> >
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Google Web Toolkit" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected]<google-web-toolkit%[email protected]>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/google-web-toolkit?hl=en.
>>
>>
>
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
