IRC channel logs
2025-12-02.log
back to list of logs
<damo22>azert: when the timeout is either cancelled or expires, it makes sense to set the callback to null, but when i do that, it expires again and fails the assert fcn != 0 <damo22>maybe the callout is being set again without the fcn being reset? <damo22>youpi: can you see a problem with not making a copy of a timeout element if i want to schedule a timeout? <damo22>eg can i reuse thread->timer in a callout wheel? <damo22>ok it hangs because elapsed_ticks stops advancing <damo22>somehow my code is stuck in a loop in the clock interrupt <damo22>$19 = {chain = {next = 0xf59b427c, prev = 0xf59b427c}, fcn = 0xc103a270 <thread_timeout>, param = 0xf618c738, t_time = 295, <damo22>how come queue_empty(&t->chain) is not true? <damo22> t = (timeout_t)queue_next(&t->chain); <damo22>it keeps running queue_next forever <azert>damo22: how can this be? Is there a race condition? <azert>is that happening in softclock or in timeout_reset? <azert>is that cycling on a deactivated timeout? <azert>maybe the empty queue check in timeout_reset need to change in the sense that if the queue is empty nextsoftcheck need to be set to NULL? <damo22>my understanding of queue.h and the pointer arithmetic is doing my head in <azert>damo22: I think the issue is aube in timeout_reset <azert>that should be more properly called timeout_stop <azert>the issue happens when you try to stop the timeout that is already in nextsoftcheck, and it happens that it is the only timeout in the queue <azert>another issue, maybe, is when you set nextsoftcheck in softclock, that you should first check if the queue is empty and if it is then set it to null <azert>Queues in gnumach and FreeBSD are defined clearly differently <azert>queue_next on an empty queue keeps giving you the same element. I think on FreeBSD that might give you NULL