IRC channel logs
2024-07-10.log
back to list of logs
<damo22>youpi: how can i grow or shrink a linked list inside timer interrupt? <damo22>since there is no kalloc/kfree inside an interrupt? <youpi>is the additional element not allocatable in advance ? <youpi>usually when you receive an interrupt it's for a reason that is known in advance <youpi>not in the case of a network card for instance, but you can pre-reserve a slot to note that the interrupt happened, and wake some thread that will achieve the actually work <damo22>basically when a timer is set i need to call set_timeout() and reset_timeout() etc <damo22>and that needs to allocate and free memory <youpi>I don't know the call-wheel structure you mentioned, but for timers, you know in advance what you'll have to manage <youpi>(theoretical work on operating systems are interesting, but quite often they are impractical because they didn't actually try to implement in a real OS...) <damo22>where each offset into the ring is the list of timeouts expiring at tick T <damo22>so to find the expiring timeouts its O(1) <damo22>plus a traversal of a small list <damo22>ok so i think the problem is freeing the memory in the timer interrupt when the timeout expires <damo22>it calls the fcn(param) and then needs to free the memory for the deleted element <damo22>is there a way to do a deferred kfree <youpi>you can put it on a to-be-freed list <youpi>but I'm wondering: do we really have many timers? <youpi>the to-be-freed list can be e.g. inspected when you want to add a new timer, you can actually reuse the allocated item instead of freeing/reallocating <damo22>every thread uses a timer for wakeups <damo22>youpi: every thread uses a timer for wakeups <damo22>im close but now im getting x139 ../ipc/ipc_mqueue.c:627: ipc_mqueue_receive: Assertion `option & MACH_RCV_TIMEOUT' failed.Debugger invoked: assertion failure <damo22>where x139 means timer expired at 139 ticks but the elapsed_ticks is 140 somehow