fibaro.setTimeout

[henri-allauch]

je ne retrouve plus la difficulté rencontrée lors de test d'enchainement de plusieurs net.HTTPClient pour des requêtes asynchrone

mais je me suis inspiré de Network Monitor qui utilise quasi systématiquement  fibaro:setTimeOut(0,function() ..... et  mon problème a été résolu.

 

j'enchainais plusieurs appel self:CommandTeracom("r1", 1) remplacé depuis par :  fibaro.setTimeout(0, function() self:CommandTeracom("r1", 1) end)

function QuickApp:CommandTeracom(Switch,Etat)

    self:trace("Switch = " ..Switch .." Etat = " ..Etat)

    self.Teracom = net.HTTPClient({timeout = 1000}) 
    url = "http://192.168.1.59"

    command = "/status.xml?" ..Switch .."=" ..Etat

    self.Teracom:request(url ..command , {
        options = {
            method = "GET"
        },
        success = function(response) 
            --self:debug(response.status)
            --self:debug(response.data)
        end,
        error = function(message)
            self:debug("error:", "CommandTeracom " ..message)
        end
    })
end

 

 

cela provoque une exécution immediate  mais quelle difference avec l'appel de la fonction sans le setTimeOut à 0  

Quelle est l'importance du  fibaro.setTimeout(0 dans l'appel des  requêtes  net.HTTPClient  asynchrones ou autres ?

 

Modifié le 3 mars 2021 par henri-allauch

[Lazer]

Déjà il faut bien que tu comprennes la notion d'asynchronisme, et donc l'ordre d'exécution des instructions lors d'une requête http:request()

Relis mon mini-tuto ici si ce n'est pas clair :

 

 

 

Donc dès que tu commences à avoir de l'asynchronisme dans ton code, il faut se méfier des appels de fonctions synchrones.

Car tout ce qui est exécuté pendant l'appel de cette fonction synchrone (et les éventuels sous-fonctions appelées, etc) vont bloquer la suite du code, et surtout les autres parties de code en asynchrone qui sont en attente d'être exécutées.

 

A l'inverse, appeler une fonction avec setTimeout, même avec un retard de 0 secondes, va placer cet appel dans la fil d'attente des appels asynchrones, et donc l'exécuter soit tout de suite s'il elle est seule, soit après les autres fonctions en attente.

 

Ainsi on rétablie l'ordre "normal" des choses. Je met entre guillemets, car l'ordre normal, c'est celui que le programmeur a décidé (sans faire d'erreurs de logique, rappelons nous que les bugs informatiques sont d'origine humaine). Parfois on veut maitriser quel code doit s'exécuter avant tel autre, parfois on préfère laisser le système gérer. Une requête http est un bon exemple, car elle dépend d'une machine tiers sur le réseau, on (= le programmeur) ne maitrise pas sa durée (car elle dépend du réseau, du serveur en face, etc), donc dans ce cas on préfère laisser le système nous rendre la main tout de suite pour faire autre chose, puis la fonction success() ou error() est appelée en callback plus tard, lorsque la réponse arrive, ou non.

 

En fait, ce mode de fonctionnement asynchrone du LUA, c'est un pseudo mode de fonctionnement multi-threadé comme on l'aurait dans un vrai programme écrit en C par exemple. Mais en plus simple (car le vrai multi-thread c'est vraiment complexe à gérer)

 

 

[henri-allauch]

il y a 53 minutes, Lazer a dit :

appeler une fonction avec setTimeout, même avec un retard de 0 secondes, va placer cet appel dans la fil d'attente des appels asynchrones, et donc l'exécuter soit tout de suite s'il elle est seule, soit après les autres fonctions en attente

Cette notions de fille d'attente des appel me convient très bien