Newest at the top
| 2026-01-23 13:31:53 +0100 | <tomsmeding> | bwe: it kind of sounds like atomicModifyIORef' is good enough; if it isn't, come back |
| 2026-01-23 13:31:31 +0100 | <bwe> | tomsmeding: I simply need to update a state from db. Effectively swapping the old data for the new data. I am not sure how can I tell right now whether the type of atomicModifyIORef' fits my use case, though. |
| 2026-01-23 13:31:20 +0100 | <tomsmeding> | (you can get correct + fast + convenient if you never need to communicate between threads! Read-only shared data works very well ;p) |
| 2026-01-23 13:28:28 +0100 | <tomsmeding> | TVar is convenient and correct across the board (programming with STM is great!), but depending on your application's behaviour it may not be very fast |
| 2026-01-23 13:27:49 +0100 | <tomsmeding> | IORefs are plenty convenient if all you need is atomicModifyIORef', but they are rather limited otherwise |
| 2026-01-23 13:27:31 +0100 | <tomsmeding> | bwe: it's more how you use them, although neither MVar nor TVar are particularly fast (STM is just the framework around TVar so not a separate thing) |
| 2026-01-23 13:26:38 +0100 | <bwe> | tomsmeding: how would we categorize MVar, TVar, STM, IORef into two out of three of: correct, fast, convenient? |
| 2026-01-23 13:26:37 +0100 | <tomsmeding> | bwe: if the type of atomicModifyIORef' (mind the ') is good enough for you, it's almost guaranteed to be the fastest option |
| 2026-01-23 13:26:18 +0100 | xff0x | (~xff0x@2405:6580:b080:900:3b58:3b23:6c7:a174) |
| 2026-01-23 13:26:02 +0100 | <bwe> | Axman6, mauke: that's exactly what I want to do, I know when I've got new data and only then want to update the IORef / MVar. -- So if I only want to swap something out, I'd be fine with an IORef? |
| 2026-01-23 13:25:28 +0100 | hakutaku | (~textual@chen.yukari.eu.org) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2026-01-23 13:25:13 +0100 | <tomsmeding> | merijn: what do you mean? |
| 2026-01-23 13:20:35 +0100 | <merijn> | tomsmeding: MVar doesn't have to ever lock and queue if you don't want to, though |
| 2026-01-23 13:18:10 +0100 | <merijn> | int-e: Bad STM design can easily cause that |
| 2026-01-23 13:17:59 +0100 | <merijn> | int-e: Almost surely |
| 2026-01-23 13:10:54 +0100 | Googulator23 | (~Googulato@team.broadbit.hu) (Quit: Client closed) |
| 2026-01-23 13:10:54 +0100 | Googulator25 | (~Googulato@team.broadbit.hu) |
| 2026-01-23 13:05:33 +0100 | comonad | (~comonad@p200300d02722ae00dce4ce9451b59974.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2026-01-23 13:03:09 +0100 | <tomsmeding> | (you may be thinking of ForeignPtr, which does implement Ord) |
| 2026-01-23 13:01:37 +0100 | Googulator23 | (~Googulato@team.broadbit.hu) |
| 2026-01-23 13:00:51 +0100 | <tomsmeding> | Axman6: MVar doesn't implement Ord, only Eq |
| 2026-01-23 12:57:54 +0100 | <tomsmeding> | int-e: I'm not aware of any, I'm an academic |
| 2026-01-23 12:57:29 +0100 | fp1 | fp |
| 2026-01-23 12:57:29 +0100 | fp | (~Thunderbi@2001:708:20:1406::10c5) (Ping timeout: 265 seconds) |
| 2026-01-23 12:57:27 +0100 | <ncf> | Leary: i didn't mean to encapsulate general recursion tbh, only to point out that the clarity of expressing things in terms of (co)algebras needn't come at the price of general recursion |
| 2026-01-23 12:57:22 +0100 | <tomsmeding> | concurrent programming: correct, fast, convenient; pick 2 |
| 2026-01-23 12:57:16 +0100 | <int-e> | Do we have any canonical STM horror story (along the lines of "it worked great until we ran it in production with 50 simultaneous threads and then it spent 90% of its time retrying STM transactions"?) |
| 2026-01-23 12:56:51 +0100 | fp1 | (~Thunderbi@2001:708:150:10::9d7e) fp |
| 2026-01-23 12:56:28 +0100 | <tomsmeding> | *as it has similar |
| 2026-01-23 12:56:14 +0100 | <tomsmeding> | and if you are worried about performance implications of using an MVar over an IORef, you should also be worried about STM, as it similar (?) overhead, and also has starvation issues if you have very long and also very short transactions that update the same TVars |
| 2026-01-23 12:53:26 +0100 | <int-e> | You can perhaps criticize the IORef docs for not mentioning STM, but the reason for that is probably historical, and you'll find out about STM when you read the MVar docs. |
| 2026-01-23 12:53:23 +0100 | <tomsmeding> | (if you only ever lock such locks in a particular global order, this problem cannot arise) |
| 2026-01-23 12:53:20 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2026-01-23 12:53:01 +0100 | <tomsmeding> | (for completeness: you have two locks, A and B, and two threads, 1 and 2. 1 locks A and then B, and 2 locks B and then A. If the two executions interleave, 1 has A locked and 2 has B locked and they both wait on the other, indefinitely) |
| 2026-01-23 12:52:41 +0100 | <__monty__> | You may be right. |
| 2026-01-23 12:52:03 +0100 | <tomsmeding> | if anything, having to order locks to avoid deadlock is a more insidious risk that you may not see coming if you haven't studied concurrent programming |
| 2026-01-23 12:51:27 +0100 | <tomsmeding> | __monty__: while yes, adding another IORef later means you can't update both in the same atomic transaction, I'm not sure what part of the API would lead one to assume that you can |
| 2026-01-23 12:50:41 +0100 | Googulator23 | (~Googulato@team.broadbit.hu) (Ping timeout: 272 seconds) |
| 2026-01-23 12:49:47 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Read error: Connection reset by peer) |
| 2026-01-23 12:48:20 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-01-23 12:45:34 +0100 | <danz20169> | maybe just passed them as black boxes |
| 2026-01-23 12:44:39 +0100 | <danz20169> | did you use any library to encode PNGs as types? |
| 2026-01-23 12:43:10 +0100 | <danz20169> | seems a solution suited to server-side data vis |
| 2026-01-23 12:41:34 +0100 | <Axman6> | I have also done that - it needed to serve images of some live-ish data, and generating the images was pretty slow, so with each new piece of data it'd just make new PNGs and update the map in the IORef. Meant all the HTTP requests were instant |
| 2026-01-23 12:41:08 +0100 | <mauke> | worked great |
| 2026-01-23 12:40:41 +0100 | <mauke> | there was a writer thread that would occasionally update the structure by just overwriting the Map |
| 2026-01-23 12:40:19 +0100 | <mauke> | I had a server that would answer client queries from a central data structure (a Map stored in an IORef) |
| 2026-01-23 12:39:57 +0100 | <Axman6> | they can store an arbitrarily complicated record too, and aMIOref can be used to update as much or as little of that structure as you like |
| 2026-01-23 12:39:05 +0100 | <mauke> | or a Map |
| 2026-01-23 12:39:04 +0100 | <Axman6> | I've been reading a lot of the Cardano code recently, and they make a lot of use of STM, as well as pure data structures. |