--- Log opened Tue Mar 11 00:00:43 2025
03:24 -!- laanwj [~laanwj@user/laanwj] has quit [Ping timeout: 260 seconds]
03:24 -!- BlueMatt[m] [~bluematt@2620:6e:a000:ce11::d] has quit [Ping timeout: 260 seconds]
03:24 -!- laanwj [~laanwj@user/laanwj] has joined #bitcoin-kernel
03:26 -!- BlueMatt[m] [~bluematt@2620:6e:a000:ce11::d] has joined #bitcoin-kernel
04:56 -!- stickies-v changed the topic of #bitcoin-kernel to: Bitcoin Kernel development and usage discussion | Channel logs: https://gnusha.org/bitcoin-kernel/, https://www.erisian.com.au/bitcoin-kernel/
04:57 <@stickies-v> looks like it's working, thank you _aj_ !
05:47 <@stickies-v> TheCharlatan: is it fair to say that the entire current API is threadsafe, except for `kernel_context_destroy()` and `kernel_context_interrupt()`?
05:49 <@stickies-v> s/is threadsafe/should be threadsafe/
05:50 -!- hebasto [sid449604@id-449604.uxbridge.irccloud.com] has joined #bitcoin-kernel
06:12 <@TheCharlatan> yes, or at least that is the idea :P
06:59 -!- dergoegge [sid453889@id-453889.lymington.irccloud.com] has joined #bitcoin-kernel
07:18 <@TheCharlatan> like one of the caveats right now is that we don't keep the lock on the BlockIndex pointers after retrieving them (which I guess we also don't really in the rest of our code, and some of the race conditions we have to deal with are because of this)
09:02 <@stickies-v> i don't think i understand - why would we have to keep a lock on BlockIndex pointers after retrieving them?
09:03 <@stickies-v> do you mean that e.g. a kernel_BlockIndex* returned by `kernel_get_block_index_from_height` is not guaranteed to be the block index at that height after the function returns, because we're not holding a lock?
09:03 <@stickies-v> (i.e. anything that depends on what's the active chain)?
--- Log closed Wed Mar 12 00:00:44 2025