Newest at the top
2025-05-18 14:12:18 +0200 | tromp | (~textual@2001:1c00:3487:1b00:ace7:b293:8f4:7479) (Quit: My iMac has gone to sleep. ZZZzzz…) |
2025-05-18 14:06:56 +0200 | rvalue- | rvalue |
2025-05-18 14:06:28 +0200 | rvalue- | (~rvalue@user/rvalue) rvalue |
2025-05-18 14:05:07 +0200 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 252 seconds) |
2025-05-18 14:03:13 +0200 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
2025-05-18 13:59:43 +0200 | euleritian | (~euleritia@ip4d17f864.dynamic.kabel-deutschland.de) |
2025-05-18 13:59:10 +0200 | euleritian | (~euleritia@dynamic-176-006-136-230.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
2025-05-18 13:52:06 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
2025-05-18 13:50:41 +0200 | j1n37- | (~j1n37@user/j1n37) (Ping timeout: 248 seconds) |
2025-05-18 13:33:09 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 260 seconds) |
2025-05-18 13:30:47 +0200 | tromp | (~textual@2001:1c00:3487:1b00:ace7:b293:8f4:7479) |
2025-05-18 13:25:21 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-05-18 13:13:54 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
2025-05-18 13:08:11 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
2025-05-18 13:07:56 +0200 | LainIwakura | (~LainIwaku@user/LainIwakura) (Quit: Client closed) |
2025-05-18 13:07:49 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
2025-05-18 13:05:22 +0200 | euleritian | (~euleritia@dynamic-176-006-136-230.176.6.pool.telefonica.de) |
2025-05-18 13:03:39 +0200 | euleritian | (~euleritia@ip4d17f864.dynamic.kabel-deutschland.de) (Ping timeout: 265 seconds) |
2025-05-18 13:01:44 +0200 | jespada | (~jespada@r167-61-146-44.dialup.adsl.anteldata.net.uy) jespada |
2025-05-18 13:00:25 +0200 | zlqrvx | (~zlqrvx@2001:8003:8c8b:e00:374a:bdcb:457c:d1e3) |
2025-05-18 12:59:44 +0200 | <Rembane> | tomsmeding: It's so good. :D |
2025-05-18 12:59:28 +0200 | <tomsmeding> | so haskell is blessed :) |
2025-05-18 12:59:23 +0200 | <tomsmeding> | Rembane: it is absolutely a luxury, and it's almost impossible to do it with a sensible API in a non-pure langugae |
2025-05-18 12:59:10 +0200 | troydm | (~troydm@user/troydm) (Quit: What is Hope? That all of your wishes and all of your dreams come true? To turn back time because things were not supposed to happen like that (C) Rau Le Creuset) |
2025-05-18 12:58:45 +0200 | <tomsmeding> | there is always a probability of one finishing and getting out of the livelock, but it can take a while in the absolute worst case |
2025-05-18 12:58:21 +0200 | <tomsmeding> | on the other hand, MVar gives you fairness, whereas with STM, if you have very long transactions and multiple of those are trying to run concurrently, they can restart and restart and restart and never actually finish |
2025-05-18 12:58:07 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
2025-05-18 12:57:47 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
2025-05-18 12:57:43 +0200 | <Rembane> | tomsmeding: It just struck me that it's such a luxury to have proper transactions outside of a database. |
2025-05-18 12:57:20 +0200 | <Rembane> | \œ/ |
2025-05-18 12:57:18 +0200 | <tomsmeding> | voilà, deadlock |
2025-05-18 12:57:14 +0200 | <tomsmeding> | you can do the classical thing of having two MVars, A and B, and have thread 1 lock A and then B, and have thread 2 lock B and then A |
2025-05-18 12:56:50 +0200 | <tomsmeding> | Rembane: in some senses, STM is safer than MVar: you get actual transactions that act like transactions, in that they're atomic; with MVars, you have to do the work yourself so that you don't get into deadlocks |
2025-05-18 12:55:34 +0200 | <Rembane> | Totally. "Hi there friends, of course you want to learn this complicated thing..." |
2025-05-18 12:55:14 +0200 | <tomsmeding> | just a bit hard to pull off, sometimes |
2025-05-18 12:55:07 +0200 | <tomsmeding> | it is :) |
2025-05-18 12:55:01 +0200 | <Rembane> | tomsmeding: That's a really good trick to learn something! :D |
2025-05-18 12:54:43 +0200 | fp1 | (~Thunderbi@hof1.kyla.fi) fp |
2025-05-18 12:54:26 +0200 | <tomsmeding> | (I knew them decently well before that, but more in detail now) |
2025-05-18 12:54:14 +0200 | <tomsmeding> | Rembane: I learned them in the context of concurrency too! Specifically, in the context of having to teach concurrency to bachelor students in a course that uses haskell :p |
2025-05-18 12:52:55 +0200 | <lxsameer> | tomsmeding: that's a good summary of it |
2025-05-18 12:52:54 +0200 | tomsmeding | works almost daily with programs that use this particular ID generation trick, so I'm tainted too |
2025-05-18 12:52:20 +0200 | <tomsmeding> | lxsameer: I'm not saying you're doing the wrong thing, just indicating that what you're doing isn't very haskell-like, and the language complains by making you do ugly things. :) |
2025-05-18 12:52:07 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
2025-05-18 12:51:45 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
2025-05-18 12:51:37 +0200 | <tomsmeding> | it does just an atomic update, whereas MVar and STM do a whole lot more |
2025-05-18 12:51:24 +0200 | <tomsmeding> | it seems to me that "obviously" atomicModifyIORef' is the fastest |
2025-05-18 12:51:22 +0200 | <Rembane> | tomsmeding: Maybe that's the point. Hm... because I've learned them in the context of concurrency. |
2025-05-18 12:51:07 +0200 | <tomsmeding> | IORef is just... a mutable thing |
2025-05-18 12:50:58 +0200 | <tomsmeding> | STM doesn't give any concurrency guarantees, just the observation that in practice it works really well |