Newest at the top
| 2026-07-03 09:25:14 +0000 | <tomsmeding> | comerijn: https://tirclogv.tomsmeding.com/cal/haskell/2026-07-02?eid=aEtUaHCT7#ev-aEtUaHCT7 |
| 2026-07-03 09:24:42 +0000 | <tomsmeding> | and replacing their equivalent of line 20 with 21 fixed the problem |
| 2026-07-03 09:24:37 +0000 | <comerijn> | threadDelay 10 seems insane? |
| 2026-07-03 09:24:31 +0000 | <comerijn> | Also |
| 2026-07-03 09:24:28 +0000 | <tomsmeding> | comerijn: there was someone here yesterday who complained about very slow code and found out that they were doing this |
| 2026-07-03 09:24:20 +0000 | <jaror> | I'm just trying to make a reproducer of absentia's problem |
| 2026-07-03 09:24:03 +0000 | <tomsmeding> | so after the flushTQueue has succeeded, another transaction should be able to get in |
| 2026-07-03 09:23:56 +0000 | <comerijn> | i.e. do you really need/want a transactional queue |
| 2026-07-03 09:23:41 +0000 | <comerijn> | jaror: What exactly are you trying to do? It's not really clear from this example |
| 2026-07-03 09:23:40 +0000 | <tomsmeding> | and when it succeeds, it empties the queue |
| 2026-07-03 09:23:25 +0000 | <tomsmeding> | but: if the queue is empty, flushTQueue doesn't do any writeTVar |
| 2026-07-03 09:23:22 +0000 | <comerijn> | tomsmeding: Sure, but you still get thundering herd races if you have lots of threads |
| 2026-07-03 09:23:15 +0000 | <tomsmeding> | this is a very small transaction that runs very often, so that sounds like the prototypical "nothing else can ever do anything situation" |
| 2026-07-03 09:22:55 +0000 | <tomsmeding> | comerijn: STM is most actively unfair when you have a repeated small transaction invalidating a larger transaction |
| 2026-07-03 09:22:35 +0000 | <comerijn> | STM does **not** actively ensure that |
| 2026-07-03 09:22:24 +0000 | <comerijn> | And since we we're discussing equal division of thread activity earlier |
| 2026-07-03 09:22:10 +0000 | <comerijn> | but my point is more that, unlike MVar and other blocking operations guarantee fairness in terms of thread activity |
| 2026-07-03 09:22:10 +0000 | <tomsmeding> | they are probably slower than what's in the RTS though :p |
| 2026-07-03 09:22:00 +0000 | <tomsmeding> | you have lock-free and even wait-free STM algorithms |
| 2026-07-03 09:21:50 +0000 | <comerijn> | of course, how else would you have transactional behaviour |
| 2026-07-03 09:21:35 +0000 | <tomsmeding> | there's even locks |
| 2026-07-03 09:21:26 +0000 | <tomsmeding> | it just works most of the time |
| 2026-07-03 09:21:21 +0000 | <tomsmeding> | it has no concurrency guarantees whatsoever |
| 2026-07-03 09:21:12 +0000 | <tomsmeding> | I have a rough idea of how STM is implemented in the RTS |
| 2026-07-03 09:20:57 +0000 | <comerijn> | *Note |
| 2026-07-03 09:20:54 +0000 | <comerijn> | Not that most STM operations are **not** fair |
| 2026-07-03 09:20:45 +0000 | <comerijn> | Also |
| 2026-07-03 09:20:37 +0000 | <comerijn> | Yes |
| 2026-07-03 09:20:30 +0000 | <tomsmeding> | jaror: when main exits, the thread also exits, right? (I forget) |
| 2026-07-03 09:20:04 +0000 | <comerijn> | That is my initial spidey sense looking at that code |
| 2026-07-03 09:19:43 +0000 | foul_owl | (~kerry@94.156.149.95) foul_owl |
| 2026-07-03 09:19:38 +0000 | <comerijn> | It's especially heinous with -N |
| 2026-07-03 09:19:23 +0000 | <comerijn> | And if not, definitely try that first |
| 2026-07-03 09:19:18 +0000 | <comerijn> | I'm out of the loop if that's default yet |
| 2026-07-03 09:19:06 +0000 | <comerijn> | yeah |
| 2026-07-03 09:19:04 +0000 | <tomsmeding> | you mean +RTS -qg? |
| 2026-07-03 09:18:58 +0000 | <tomsmeding> | oh |
| 2026-07-03 09:18:53 +0000 | <comerijn> | tomsmeding: That's not what I mean |
| 2026-07-03 09:18:47 +0000 | <tomsmeding> | nonmoving GC is not default AFAIK |
| 2026-07-03 09:18:38 +0000 | <comerijn> | Or is -threaded still using parallel GC |
| 2026-07-03 09:18:37 +0000 | <jaror> | It only affects mutator time |
| 2026-07-03 09:18:36 +0000 | <tomsmeding> | comerijn: to what |
| 2026-07-03 09:18:30 +0000 | <jaror> | yeah |
| 2026-07-03 09:18:27 +0000 | <comerijn> | Did the default GC settings get changed yet? |
| 2026-07-03 09:18:23 +0000 | <tomsmeding> | jaror: if you swap line 20 for line 21? |
| 2026-07-03 09:18:17 +0000 | <comerijn> | hold up |
| 2026-07-03 09:17:54 +0000 | <jaror> | But the elapsed time does not change |
| 2026-07-03 09:17:41 +0000 | <tomsmeding> | in context it's unclear whether that diagnosis is accurate, but if it is, then the point about "task switching happens only at GC" is moot :p |
| 2026-07-03 09:17:31 +0000 | <comerijn> | There's even less reason now |
| 2026-07-03 09:17:27 +0000 | <comerijn> | That said, there was barely any reason to not use -threaded 10 years ago |