utubettl: possible bug with on_task_change?
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 35/100
Piste de recherche
Commencez par process_neighbour dans utubettl et suivez la recherche dans l’index utube ainsi que les appels à on_task_change. Examinez comment le framework utilise la tâche notifiée et comment la priorité est représentée ; le travail est terminé lorsqu’il a été déterminé si le voisin sélectionné doit être la tâche READY de priorité la plus basse et que le comportement ou la modification requis a été consigné.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
When releasing/deleting a task in utubettl, the code finds a "neighbour" task - a task with the same utube field that is in READY state. It then notifies the framework that this neighbour task is now available for taking, by calling on_task_change.
local function process_neighbour(self, task, operation)
self:on_task_change(task, operation)
if task ~= nil then
local neighbour = self.space.index.utube:min{state.READY, task[i_utube]}
if neighbour ~= nil and neighbour[i_status] == state.READY then
self:on_task_change(neighbour)
end
end
return task
end
A possible bug is that this neighbour task may not be the one with the lowest priority, because the priority field not in the "utube" index.
Currently, the framework wakes up a consumer fiber, but does not look at the particular task being passed to on_task_change, so it doesn't matter.
Is this a bug?
- Langage dominant
- Lua
- Étoiles
- 243
- Forks
- 56
- Merge moyen
- 6 j 8 h
- PR mergées (30 j)
- 1
Préparer son environnement
Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de tarantool/queue
-
tube:grant() is not documentedOuvertedocumentation good first issue
Difficulté 1/5 Moins d'une heure Accessibilité débutants 85/100
-
*ttl drivers: TTL branch dereferences delete() result without a nil check, killing the fiberPeut-être pris @maksimuimin l’a pris il y a 18 jours. Ouverte
Difficulté 3/5 1-2 jours Accessibilité débutants 76/100
-
*ttl drivers: a dead TTL fiber cannot be restarted and wedges the queue in ENDING on the next RO switchPeut-être pris @maksimuimin l’a pris il y a 18 jours. Ouverte
Difficulté 4/5 3-5 jours Accessibilité débutants 48/100
-
fifottl/limfifottl: stop() blocks forever while RW, drop() leaks the TTL fiberPeut-être pris @maksimuimin l’a pris il y a 18 jours. Ouverte
Difficulté 4/5 3-5 jours Accessibilité débutants 55/100
-
1sp bug teamE
Difficulté 4/5 3-5 jours Accessibilité débutants 25/100
Toutes les issues de tarantool/queue
Issues similaires
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 82/100
-
bug: (profiler): E484 "Can't open file .../vim/_core/shared" when stopping profiler on Neovim 0.12Ouvertebug
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
folke/snacks.nvim#2971 ·
-
severity: low
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
luainkernel/lunatik#1853 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
-
Difficulté 2/5 1-3 heures Accessibilité débutants 62/100
Les mainteneurs répondent en général sous 3 jours