Newest at the top
| 2026-03-29 23:01:39 +0200 | Guest96 | (~Guest62@p200300ca8f23fa0023c431aeeea1b74f.dip0.t-ipconnect.de) (Quit: Client closed) |
| 2026-03-29 22:59:29 +0200 | <monochrom> | In the brick-and-mortor retail world, there are only two reasons to do that (long customer queue). One is to create hype ("oh look at how many people are dying to buy our product!"). The other is in supermarkets putting pressure on cashier workers. |
| 2026-03-29 22:57:51 +0200 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2026-03-29 22:57:20 +0200 | <monochrom> | listen(a number in the order of thousands) is simply mean. |
| 2026-03-29 22:53:22 +0200 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 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 |