Newest at the top
| 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 |
| 2025-05-18 12:50:43 +0200 | LainIwakura | (~LainIwaku@user/LainIwakura) LainIwakura |
| 2025-05-18 12:50:41 +0200 | <tomsmeding> | Rembane: MVar is a mutable variable with guaranteed FIFO queueing; STM is optimistic concurrency that has various sources of overhead but avoids locking in the happy path of no contention |
| 2025-05-18 12:50:08 +0200 | <lxsameer> | ah sorry, it wasn't for me |
| 2025-05-18 12:49:53 +0200 | <lxsameer> | tomsmeding: no, I'm trying to port a legacy code (which is in very old scheme) to haskell, what is happening there is not necessarily the right way to implement it in haskell |
| 2025-05-18 12:49:47 +0200 | <Rembane> | Got it! |
| 2025-05-18 12:49:41 +0200 | <tomsmeding> | (in this particular application) |
| 2025-05-18 12:49:38 +0200 | <Rembane> | tomsmeding: Maybe I have misunderstood everything but I thought MVar was more safe than STM that was more safe than IORef, but I don't know why. So it might just be something I got wrong. |
| 2025-05-18 12:49:27 +0200 | <tomsmeding> | the move from MVar to STM lost fairness; I would not call that "safety", but it's perhaps close enough. But STM -> IORef doesn't lose anything |
| 2025-05-18 12:48:43 +0200 | <tomsmeding> | Rembane: why less safe? |