GWT Single threaded callbacks asynchrones

Question

rpc.call(mycallback);

{
//subsequent code block

}

1. Comment fonctionne le callback asynchrone à fil unique ?
2. Quand le callback sera-t-il appelé ?
3. Le bloc de code suivant finira-t-il toujours de s'exécuter avant que la fonction de rappel ne soit autorisée à s'exécuter (c'est-à-dire que la fonction de rappel ne s'exécutera que lorsque tout le code sera terminé) ?

Answer 1

Avec GWT-RPC, un callback asynchrone ressemble à ceci :

AsyncCallback<ResultBean> callback = new AsyncCallback<ResultBean>() {
    public void onSuccess(ResultBean result) {
        // Code to run once callback completes
    }

    public void onFailure(Throwable caught) {
        // Error handling code
    }
};

asyncService.call(callback);

// Subsequent code block

En onSuccess() sera appelée une fois que les résultats auront été reçus du serveur. Le bloc de code suivant sera exécuté avant que le callback ne soit terminé, car le single thread doit terminer l'exécution de l'événement actuel avant de pouvoir traiter le suivant dans la file d'attente. Pour s'assurer qu'un bloc de code s'exécute après la fin du callback, celui-ci doit être appelé à partir de la fonction onSuccess() méthode.

Voici une explication technique de la façon dont cela fonctionne dans un environnement à un seul thread (trouvé aquí de Thomas Broyer) :

GWT-RPC fait usage de RequestBuilder, qui est basé sur XMLHttpRequest. XMLHttpRequest (XHR) utilise des événements pour communiquer en retour avec le code, donc tout ce qui se passe sur un XHR résulte en un événement poussé sur le code. dans la file d'attente des événements, puis retiré de la file d'attente par la boucle d'événements.

Voir également le Documentation GWT .

Answer 2

Pour l'instant, il n'y a pas de différence entre

rpc.call(mycallback);
{
   //subsequent code block
}

o

{
   // code block before
}
rpc.call(mycallback);

Cependant, je ne vois aucune raison de dépendre d'un tel comportement. Si vous voulez être sûr que le bloc de code a été exécuté, utilisez la deuxième version

Answer 3

Le javascript #1 est single-thread, mais le navigateur ne l'est pas, donc le js-thread envoie l'appel xhr au navigateur pour le résoudre, et le navigateur lui renvoie le contrôle immédiatement.

2 lorsque le navigateur reçoit la réponse du serveur, il met en file d'attente le callback dans le thread js, de sorte qu'il sera exécuté lorsque js aura terminé ce qu'il pourrait être en train d'exécuter maintenant (dans votre cas, le bloc de code suivant).

3 oui, car l'exécution monotone de ce bloc empêche l'exécution de tout autre code différé (timeouts, callbacks) jusqu'à ce qu'il soit terminé.

Answer 4

Comme l'appel est effectué de manière asynchrone, vous ne savez pas quand le serveur renvoie le callback.

Donc,

lorsque l'appel au code serveur lance le //subsequent code block commence à s'exécuter ,Et quand l'appel se termine le code dans onSuccess les blocs de code commencent à s'exécuter .

Si Bloc de code onSuccess y bloc de code suivant sont indépendants, il n'y a aucune différence entre le fait d'appeler antes de o après le serveur a frappé.

si les deux sont dépendants

rpc.call(new AsynchCallback { 
        onSucees(){
                   //subsequent code block
                  }
   });