Newest at the top
| 2026-03-29 22:42:57 +0200 | merijn | (~merijn@62.45.136.136) (Ping timeout: 269 seconds) |
| 2026-03-29 22:37:58 +0200 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-03-29 22:35:19 +0200 | pavonia | (~user@user/siracusa) siracusa |
| 2026-03-29 22:34:12 +0200 | koala_man | (~vidar@157.146.251.23.bc.googleusercontent.com) koala_man |
| 2026-03-29 22:33:27 +0200 | koala_man | (~vidar@157.146.251.23.bc.googleusercontent.com) (Read error: Connection reset by peer) |
| 2026-03-29 22:33:06 +0200 | srazkvt | (~sarah@user/srazkvt) (Quit: Konversation terminated!) |
| 2026-03-29 22:30:55 +0200 | machinedgod | (~machinedg@d172-219-48-230.abhsia.telus.net) (Ping timeout: 264 seconds) |
| 2026-03-29 22:30:29 +0200 | <TMA> | that might be a problem |
| 2026-03-29 22:29:04 +0200 | <tomsmeding> | through this function https://hackage-content.haskell.org/package/streaming-commons-0.2.3.1/docs/src/Data.Streaming.Netw… |
| 2026-03-29 22:28:58 +0200 | <tomsmeding> | TMA: following the call chain, warp seems to pass 2048 there |
| 2026-03-29 22:28:11 +0200 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 244 seconds) |
| 2026-03-29 22:27:19 +0200 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-29 22:26:48 +0200 | emmanuelux | (~em@user/emmanuelux) emmanuelux |
| 2026-03-29 22:25:08 +0200 | <TMA> | [exa]: there is a parameter to listen(2) that limits how many unaccepted connections are waiting. setting it to 5 or 3 is fine for the normal case of acepting often |
| 2026-03-29 22:23:42 +0200 | emmanuelux | (~em@user/emmanuelux) (Read error: Connection reset by peer) |
| 2026-03-29 22:22:36 +0200 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-29 22:21:50 +0200 | takuan | (~takuan@d8D86B9E9.access.telenet.be) (Ping timeout: 256 seconds) |
| 2026-03-29 22:19:28 +0200 | jreicher | (~joelr@user/jreicher) jreicher |
| 2026-03-29 22:17:47 +0200 | marinelli | (~weechat@gateway/tor-sasl/marinelli) marinelli |
| 2026-03-29 22:17:27 +0200 | marinelli | (~weechat@gateway/tor-sasl/marinelli) (Remote host closed the connection) |
| 2026-03-29 22:17:17 +0200 | jmcantrell_ | (~weechat@user/jmcantrell) jmcantrell |
| 2026-03-29 22:13:11 +0200 | <[exa]> | nah, you still need a state machine there, doesn't help. |
| 2026-03-29 22:11:51 +0200 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 255 seconds) |
| 2026-03-29 22:07:15 +0200 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-29 22:05:42 +0200 | <tomsmeding> | I don't know how it works but a friend does and he's happy for reasons complementary to what you seem to not like in tcp |
| 2026-03-29 22:05:22 +0200 | <tomsmeding> | then I bet you're happier with QUIC |
| 2026-03-29 22:04:40 +0200 | <[exa]> | :D |
| 2026-03-29 22:04:38 +0200 | <[exa]> | in other news I'm not a great fan of tcp |
| 2026-03-29 22:04:19 +0200 | <tomsmeding> | yes |
| 2026-03-29 22:04:14 +0200 | <[exa]> | "not accepted" means "queued forever in the OS" which might be worse |
| 2026-03-29 22:04:02 +0200 | <tomsmeding> | hm |
| 2026-03-29 22:03:55 +0200 | <tomsmeding> | with the downside being that connections that go over the limit are accepted and then dropped instead of not accepted |
| 2026-03-29 22:03:37 +0200 | <[exa]> | and failing early is actually the recommended behavior in congestion, so I think it's okay-ish |
| 2026-03-29 22:03:35 +0200 | <tomsmeding> | oh right and because accept() is called in a sequential loop, this way you can limit the number of open sockets |
| 2026-03-29 22:02:58 +0200 | <tomsmeding> | heh |
| 2026-03-29 22:02:48 +0200 | <[exa]> | tomsmeding: well if you don't fork, the socket is killed and you have an acceptable state again (oh so punny) |
| 2026-03-29 22:02:03 +0200 | mistivia | (~mistivia@user/mistivia) (Remote host closed the connection) |
| 2026-03-29 22:01:37 +0200 | <tomsmeding> | then again, there's supposedly some EMFILE handling around the accept(2) call, but not sure if that actually does anything |
| 2026-03-29 22:01:13 +0200 | <tomsmeding> | [exa]: I looked at the warp source code and it seemed like the accept already happens before the fork, so putting a semaphore in settingsFork doesn't seem like it really blocks accept |
| 2026-03-29 22:01:09 +0200 | marinelli | (~weechat@gateway/tor-sasl/marinelli) marinelli |
| 2026-03-29 22:00:48 +0200 | notzmv | (~umar@user/notzmv) (Ping timeout: 246 seconds) |
| 2026-03-29 22:00:42 +0200 | marinelli | (~weechat@gateway/tor-sasl/marinelli) (Remote host closed the connection) |
| 2026-03-29 22:00:09 +0200 | <[exa]> | tomsmeding: tested the thing with the semaphore in the handler before fork, it apparently worked, so now it's stashed until I actually need it |
| 2026-03-29 21:56:43 +0200 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-29 21:55:38 +0200 | Lord_of_Life_ | Lord_of_Life |
| 2026-03-29 21:54:45 +0200 | koala_man | (~vidar@157.146.251.23.bc.googleusercontent.com) koala_man |
| 2026-03-29 21:54:00 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 268 seconds) |
| 2026-03-29 21:52:46 +0200 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-03-29 21:51:52 +0200 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-29 21:48:15 +0200 | target_i | (~target_i@user/target-i/x-6023099) target_i |