Dans les logiciels en temps réel, les demandes de réseau ou les opérations de contrôle sur les machines prennent beaucoup de temps par rapport aux opérations logicielles quotidiennes. Par exemple, le fait de dire à un moteur pas à pas d'avancer vers une position particulière peut prendre quelques secondes, alors que les opérations normales peuvent prendre quelques millisecondes. Disons que l'avance typique d'un moteur pas à pas prend n millisecondes, et celle qui atteint la distance maximale prend m millisecondes. Un délai d'expiration agressif calcule n et ajoute un petit facteur de fudge, peut-être 10%, et échoue rapidement si l'objectif n'a pas été atteint à ce moment-là. Comme vous l'avez indiqué, le délai d'attente agressif vous permettra de libérer des ressources. Un délai d'expiration non agressif de m plus epsilon échouerait beaucoup plus lentement et immobiliserait des ressources inutilement.
Dans le monde du logiciel asynchrone, il existe un certain nombre d'autres choix entre succès et échec. Une opération asynchrone peut également calculer n plus 10%, et mettre en place une barre de progression (si les commentaires des utilisateurs sont souhaités), puis montrer la progression vers la fin de l'objectif estimé. Lorsque le délai d'expiration est atteint, la barre de progression est pleine, mais vous risquez de la faire clignoter ou de changer de couleur pour indiquer qu'elle prend plus de temps que prévu. Si le moteur pas à pas n'a toujours pas atteint son objectif après m millisecondes, vous pouvez annoncer un échec.
Dans d'autres cas, lorsque le commentaire n'est pas important, vous pouvez certainement utiliser m plus epsilon comme délai d'expiration.
Les délais d'attente sont nécessaires quel que soit. Par exemple, supposons que vous faites quelque chose dans le réseau; peu importe si c'est asynchrone et non bloquant, vous ne saurez jamais le résultat ... vous voudriez donc avoir une fenêtre établie où les choses sont considérées comme réussies ou non. –