2025/11/19

Newest at the top

2025-11-19 21:43:41 +0100Googulator98Googulator
2025-11-19 21:42:07 +0100petrichor(~jez@user/petrichor) petrichor
2025-11-19 21:39:06 +0100petrichor(~jez@user/petrichor) (Read error: Connection reset by peer)
2025-11-19 21:39:06 +0100Square3(~Square@user/square) (Ping timeout: 256 seconds)
2025-11-19 21:36:06 +0100Square2(~Square4@user/square) Square
2025-11-19 21:35:14 +0100jmcantrell(~weechat@user/jmcantrell) jmcantrell
2025-11-19 21:34:22 +0100weary-traveler(~user@user/user363627) (Remote host closed the connection)
2025-11-19 21:34:21 +0100sord937(~sord937@gateway/tor-sasl/sord937) (Quit: sord937)
2025-11-19 21:34:21 +0100ljdarj(~Thunderbi@user/ljdarj) ljdarj
2025-11-19 21:32:18 +0100Digit(~user@user/digit) (Read error: Connection reset by peer)
2025-11-19 21:27:51 +0100weary-traveler(~user@user/user363627) user363627
2025-11-19 21:23:41 +0100weary-traveler(~user@user/user363627) (Read error: Connection reset by peer)
2025-11-19 21:20:45 +0100ljdarj(~Thunderbi@user/ljdarj) (Ping timeout: 245 seconds)
2025-11-19 21:16:16 +0100ljdarj1ljdarj
2025-11-19 21:16:16 +0100ljdarj(~Thunderbi@user/ljdarj) (Ping timeout: 255 seconds)
2025-11-19 21:15:44 +0100Googulator98(~Googulato@2a01-036d-0106-0231-4475-80b4-5cdc-43d6.pool6.digikabel.hu)
2025-11-19 21:15:36 +0100Googulator98(~Googulato@2a01-036d-0106-0231-4475-80b4-5cdc-43d6.pool6.digikabel.hu) (Quit: Client closed)
2025-11-19 21:14:15 +0100ljdarj1(~Thunderbi@user/ljdarj) ljdarj
2025-11-19 21:05:40 +0100Lycurgus(~juan@user/Lycurgus) (Quit: alsoknownas.renjuan.org ( juan@acm.org ))
2025-11-19 20:55:32 +0100ljdarj1ljdarj
2025-11-19 20:55:32 +0100ljdarj(~Thunderbi@user/ljdarj) (Ping timeout: 244 seconds)
2025-11-19 20:55:16 +0100ljdarj1(~Thunderbi@user/ljdarj) ljdarj
2025-11-19 20:52:05 +0100Nachtgespenst(~user@user/siracusa) siracusa
2025-11-19 20:49:13 +0100aditya_an1l(~aditya_an@user/aditya-an1l:63825) (Quit: WeeChat 4.7.1)
2025-11-19 20:44:52 +0100ljdarj(~Thunderbi@user/ljdarj) ljdarj
2025-11-19 20:44:38 +0100ljdarj(~Thunderbi@user/ljdarj) (Quit: ljdarj)
2025-11-19 20:35:54 +0100jmcantrell(~weechat@user/jmcantrell) (Ping timeout: 252 seconds)
2025-11-19 20:34:59 +0100Googulator98(~Googulato@2a01-036d-0106-0231-4475-80b4-5cdc-43d6.pool6.digikabel.hu)
2025-11-19 20:34:34 +0100Googulator98(~Googulato@2a01-036d-0106-0231-4475-80b4-5cdc-43d6.pool6.digikabel.hu) (Quit: Client closed)
2025-11-19 20:29:37 +0100jmcantrell(~weechat@user/jmcantrell) jmcantrell
2025-11-19 20:27:27 +0100Tuplanolla(~Tuplanoll@91-152-225-194.elisa-laajakaista.fi) Tuplanolla
2025-11-19 20:25:43 +0100ljdarj(~Thunderbi@user/ljdarj) ljdarj
2025-11-19 20:25:26 +0100ljdarj(~Thunderbi@user/ljdarj) (Quit: ljdarj)
2025-11-19 20:25:09 +0100jmcantrell(~weechat@user/jmcantrell) (Quit: WeeChat 4.7.1)
2025-11-19 20:23:16 +0100 <[exa]> yap
2025-11-19 20:21:50 +0100 <tomsmeding> not due to those locks in any case
2025-11-19 20:21:29 +0100 <tomsmeding> [exa]: if you take the locks in a globally consistent order there are no deadlocks
2025-11-19 20:21:24 +0100aditya_an1l(~aditya_an@user/aditya-an1l:63825) aditya_an1l
2025-11-19 20:20:51 +0100 <[exa]> (it's got a name in DBMSes but I don't remember that name)
2025-11-19 20:20:26 +0100 <[exa]> "properly bracketed" = acquire all locks in predictable order ideally before any work starts, release them in reverse order. If you manage to have a global predictable order, there's no deadlocks. If there's still a deadlock, at least you get an exception which doesn't interrupt any actual work and retrying is cheap&safe
2025-11-19 20:20:01 +0100jmcantrell(~weechat@user/jmcantrell) jmcantrell
2025-11-19 20:19:19 +0100Inline(~inlinE@2001-4dd7-ae97-0-4674-ae6d-2607-c022.ipv6dyn.netcologne.de) Inline
2025-11-19 20:18:46 +0100 <tomsmeding> because relying on that sounds like asking for trouble
2025-11-19 20:17:43 +0100 <tomsmeding> [exa]: what do you mean with properly bracketed? Do you mean that the runtime would throw a "blocked indefinitely on MVar" exception and kill one of the threads?
2025-11-19 20:13:40 +0100 <[exa]> tomsmeding: at least the deadlocks are usually solvable&preemptable if the locks are properly bracketed
2025-11-19 20:10:26 +0100 <tomsmeding> EvanR: and then you have two exclusive resources and you don't take the locks in the right order and you deadlock
2025-11-19 20:06:52 +0100 <[exa]> int-e tomsmeding: to solve the backtick situation I propose -XFronTicks that gives a proper ` id ยด
2025-11-19 20:05:29 +0100 <[exa]> merijn: can you re-use the postgresql one?
2025-11-19 20:01:42 +0100tomboy64(~tomboy64@user/tomboy64) tomboy64
2025-11-19 19:59:50 +0100tomboy64(~tomboy64@user/tomboy64) (Ping timeout: 244 seconds)