Newest at the top
| 2026-04-14 13:46:50 +0000 | uli-fem | (~uli-fem@203.87.114.209) |
| 2026-04-14 13:46:36 +0000 | <[exa]> | (who's don syme) |
| 2026-04-14 13:46:14 +0000 | <[exa]> | yeah the count of the green threads isn't a big issue, the resource exhaustion that happens if each of the threads starts nibbling is the issue |
| 2026-04-14 13:45:17 +0000 | <gentauro> | and lets not talk Erlang/Elixir |
| 2026-04-14 13:45:04 +0000 | <gentauro> | but he showed how F# easily could handle a mil green-threads |
| 2026-04-14 13:44:44 +0000 | <gentauro> | [exa]: I recall Don Syme had a MS blog post (his blog is gone since he was "moved" to GitHub Next) |
| 2026-04-14 13:43:20 +0000 | <[exa]> | like, can the usual kernel keep 1M TCP connections open? |
| 2026-04-14 13:41:04 +0000 | xff0x | (~xff0x@2405:6580:b080:900:763c:362b:b9c4:6a52) |
| 2026-04-14 13:40:16 +0000 | <gentauro> | thx :) |
| 2026-04-14 13:37:58 +0000 | xff0x | (~xff0x@2405:6580:b080:900:763c:362b:b9c4:6a52) (Ping timeout: 268 seconds) |
| 2026-04-14 13:35:03 +0000 | karenw | (~karenw@user/karenw) karenw |
| 2026-04-14 13:34:41 +0000 | karenw | (~karenw@user/karenw) (Remote host closed the connection) |
| 2026-04-14 13:32:11 +0000 | <[exa]> | gentauro: 1M is possible for sure, even more I'd say; the main concern is that at that point I don't really see an engineeringly correct use-case for that |
| 2026-04-14 13:25:32 +0000 | karenw | (~karenw@user/karenw) karenw |
| 2026-04-14 13:25:27 +0000 | Digit | (~user@user/digit) Digit |
| 2026-04-14 13:23:25 +0000 | ystael | (~ystael@user/ystael) ystael |
| 2026-04-14 13:20:39 +0000 | AlexZenon | (~alzenon@178.34.151.36) |
| 2026-04-14 13:18:06 +0000 | uli-fem | (~uli-fem@203.87.114.209) (Ping timeout: 246 seconds) |
| 2026-04-14 13:16:49 +0000 | leppard | (~noOne@ipservice-092-208-182-236.092.208.pools.vodafone-ip.de) Inline |
| 2026-04-14 13:15:41 +0000 | <Leary> | gentauro: It's possible, but that doesn't mean it's a good idea. I rather suspect it will induce a bunch of GC overhead you don't want, which could probably be avoided by some kind of work queue. |
| 2026-04-14 13:15:33 +0000 | <mauke> | (number of threads, I mean) |
| 2026-04-14 13:15:25 +0000 | <mauke> | it definitely went into the 100,000s |
| 2026-04-14 13:15:06 +0000 | <mauke> | I did a linear bucket chain of threads connected by MVars, maybe 15 years ago? |
| 2026-04-14 13:14:19 +0000 | <mauke> | I don't remember what my record was |
| 2026-04-14 13:13:52 +0000 | uli-fem | (~uli-fem@203.87.114.209) |
| 2026-04-14 13:11:53 +0000 | tromp | (~textual@2001:1c00:340e:2700:f5bd:97ff:8f76:c38c) |
| 2026-04-14 13:11:29 +0000 | <gentauro> | would it be possible to spawn 1m concurrent `https://hackage-content.haskell.org/package/async-2.2.6/docs/Control-Concurrent-Async.html` (green threads right?) as we can do in Rust/dotnet: https://hez2010.github.io/async-runtimes-benchmarks-2024/take2.html |
| 2026-04-14 13:08:58 +0000 | Digit | (~user@user/digit) (Ping timeout: 276 seconds) |
| 2026-04-14 13:08:46 +0000 | AlexNoo | (~AlexNoo@178.34.151.36) |
| 2026-04-14 13:06:47 +0000 | tromp | (~textual@2001:1c00:340e:2700:f5bd:97ff:8f76:c38c) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2026-04-14 12:58:14 +0000 | uli-fem | (~uli-fem@203.87.114.209) (Ping timeout: 256 seconds) |
| 2026-04-14 12:57:31 +0000 | AlexNoo | (~AlexNoo@178.34.151.36) (Quit: Leaving) |
| 2026-04-14 12:56:42 +0000 | AlexZenon | (~alzenon@178.34.151.36) (Quit: ;-) |
| 2026-04-14 12:56:17 +0000 | alter2000 | (~alter2000@user/alter2000) alter2000 |
| 2026-04-14 12:53:30 +0000 | uli-fem | (~uli-fem@203.87.114.209) |
| 2026-04-14 12:49:37 +0000 | alter2000 | (~alter2000@user/alter2000) (Ping timeout: 244 seconds) |
| 2026-04-14 12:44:56 +0000 | puke | (~puke@user/puke) (Ping timeout: 250 seconds) |
| 2026-04-14 12:42:24 +0000 | uli-fem | (~uli-fem@203.87.114.209) (Ping timeout: 245 seconds) |
| 2026-04-14 12:38:48 +0000 | tromp | (~textual@2001:1c00:340e:2700:f5bd:97ff:8f76:c38c) |
| 2026-04-14 12:37:54 +0000 | uli-fem | (~uli-fem@203.87.114.209) |
| 2026-04-14 12:33:26 +0000 | alter2000 | (~alter2000@user/alter2000) alter2000 |
| 2026-04-14 12:25:39 +0000 | alter2000 | (~alter2000@user/alter2000) (Ping timeout: 255 seconds) |
| 2026-04-14 12:15:04 +0000 | <Milan_Vanca> | Program executed on all cores only first 5s from 25s total. So it looks like it oveflowed sparks or something. |
| 2026-04-14 12:13:11 +0000 | <Milan_Vanca> | I have found this in ghc docs Any remaining sparks are discarded at the end of execution, so “converted” plus “pruned” does not necessarily add up to the total. |
| 2026-04-14 12:12:21 +0000 | <lambdabot> | 40960 |
| 2026-04-14 12:12:21 +0000 | oskarw | (~user@user/oskarw) (ERC 5.6.1 (IRC client for GNU Emacs 30.2)) |
| 2026-04-14 12:12:20 +0000 | <ski> | > 49151 - (7336 + 855) |
| 2026-04-14 12:07:52 +0000 | uli-fem | (~uli-fem@203.87.114.209) (Ping timeout: 276 seconds) |
| 2026-04-14 12:02:57 +0000 | uli-fem | (~uli-fem@203.87.114.209) |
| 2026-04-14 12:01:52 +0000 | <Milan_Vanca> | Maybe info in () shows last known state, and first number is total for whole program run. |