Logs: liberachat/#haskell
| 2026-03-29 20:01:13 | <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 20:01:37 | <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 20:02:03 | × | mistivia quits (~mistivia@user/mistivia) (Remote host closed the connection) |
| 2026-03-29 20:02:48 | <[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 20:02:58 | <tomsmeding> | heh |
| 2026-03-29 20:03:35 | <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 20:03:37 | <[exa]> | and failing early is actually the recommended behavior in congestion, so I think it's okay-ish |
| 2026-03-29 20:03:55 | <tomsmeding> | with the downside being that connections that go over the limit are accepted and then dropped instead of not accepted |
| 2026-03-29 20:04:02 | <tomsmeding> | hm |
| 2026-03-29 20:04:14 | <[exa]> | "not accepted" means "queued forever in the OS" which might be worse |
| 2026-03-29 20:04:19 | <tomsmeding> | yes |
| 2026-03-29 20:04:38 | <[exa]> | in other news I'm not a great fan of tcp |
| 2026-03-29 20:04:40 | <[exa]> | :D |
| 2026-03-29 20:05:22 | <tomsmeding> | then I bet you're happier with QUIC |
| 2026-03-29 20:05:42 | <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 20:07:15 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-03-29 20:11:51 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 255 seconds) |
| 2026-03-29 20:13:11 | <[exa]> | nah, you still need a state machine there, doesn't help. |
| 2026-03-29 20:17:17 | → | jmcantrell_ joins (~weechat@user/jmcantrell) |
| 2026-03-29 20:17:27 | × | marinelli quits (~weechat@gateway/tor-sasl/marinelli) (Remote host closed the connection) |
| 2026-03-29 20:17:47 | → | marinelli joins (~weechat@gateway/tor-sasl/marinelli) |
| 2026-03-29 20:19:28 | → | jreicher joins (~joelr@user/jreicher) |
| 2026-03-29 20:21:50 | × | takuan quits (~takuan@d8D86B9E9.access.telenet.be) (Ping timeout: 256 seconds) |
| 2026-03-29 20:22:36 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-03-29 20:23:42 | × | emmanuelux quits (~em@user/emmanuelux) (Read error: Connection reset by peer) |
| 2026-03-29 20:25:08 | <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 20:26:48 | → | emmanuelux joins (~em@user/emmanuelux) |
| 2026-03-29 20:27:19 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-29 20:28:11 | × | arandombit quits (~arandombi@user/arandombit) (Ping timeout: 244 seconds) |
| 2026-03-29 20:28:58 | <tomsmeding> | TMA: following the call chain, warp seems to pass 2048 there |
| 2026-03-29 20:29:04 | <tomsmeding> | through this function https://hackage-content.haskell.org/package/streaming-commons-0.2.3.1/docs/src/Data.Streaming.Network.html#bindPortTCP |
| 2026-03-29 20:30:29 | <TMA> | that might be a problem |
| 2026-03-29 20:30:55 | × | machinedgod quits (~machinedg@d172-219-48-230.abhsia.telus.net) (Ping timeout: 264 seconds) |
| 2026-03-29 20:33:06 | × | srazkvt quits (~sarah@user/srazkvt) (Quit: Konversation terminated!) |
| 2026-03-29 20:33:27 | × | koala_man quits (~vidar@157.146.251.23.bc.googleusercontent.com) (Read error: Connection reset by peer) |
| 2026-03-29 20:34:12 | → | koala_man joins (~vidar@157.146.251.23.bc.googleusercontent.com) |
| 2026-03-29 20:35:19 | → | pavonia joins (~user@user/siracusa) |
| 2026-03-29 20:37:58 | → | merijn joins (~merijn@62.45.136.136) |
| 2026-03-29 20:42:57 | × | merijn quits (~merijn@62.45.136.136) (Ping timeout: 269 seconds) |
| 2026-03-29 20:53:22 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-03-29 20:57:20 | <monochrom> | listen(a number in the order of thousands) is simply mean. |
| 2026-03-29 20:57:51 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2026-03-29 20:59:29 | <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 21:01:39 | × | Guest96 quits (~Guest62@p200300ca8f23fa0023c431aeeea1b74f.dip0.t-ipconnect.de) (Quit: Client closed) |
| 2026-03-29 21:04:18 | <monochrom> | And now that I think about it, even those reasons are intended to be mean (to customers in the 1st case, employees in the 2nd case). |
| 2026-03-29 21:05:34 | <tomsmeding> | putting pressure on cashier workers is indirectly also a bit mean to the supermarket, as it results in more mistakes and more missed (i.e. stolen) products, but likely the effect on the cashiers is bigger, yes |
| 2026-03-29 21:06:06 | <EvanR> | standing there with nothing to do is the worst though |
| 2026-03-29 21:07:14 | <EvanR> | having worked black friday, from my perspective it wasn't particularly different from a normal busy day, since I can't tell the diff between 5 people in my line vs 500 |
| 2026-03-29 21:07:37 | × | koala_man quits (~vidar@157.146.251.23.bc.googleusercontent.com) (Ping timeout: 268 seconds) |
| 2026-03-29 21:08:17 | <monochrom> | Pretty sure the capitalist supermarket managers have found the sweet spot of the right queue length pressure to balance between "motivation to work" and error rate. :) |
| 2026-03-29 21:08:27 | <glguy> | When I worked people who'd been waiting in a long line behaved at least a little differently from those who hadn't been waiting long |
| 2026-03-29 21:08:43 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-03-29 21:08:57 | <glguy> | I worked at a computer store in the age of mail in rebates. Every sunday lines went to the back of the store as people can in to get their free-after-rebate stuff |
| 2026-03-29 21:08:58 | <tomsmeding> | (my supermarket cashier experience is from when I was like 15 and didn't know shit) |
| 2026-03-29 21:09:23 | → | koala_man joins (~vidar@157.146.251.23.bc.googleusercontent.com) |
| 2026-03-29 21:09:42 | <EvanR> | yeah just assume the customer is baseline evil and you won't be disappointed |
| 2026-03-29 21:10:11 | <glguy> | I also worked in a movie theater back when people still lined up to see movies on the big screen and lines could get quite long |
| 2026-03-29 21:12:15 | <tomsmeding> | can we talk about dependencies? I have a simple app that uses chronos (not even all that much), mustache, warp, and some negligible other stuff. Chronos and mustache pull in aeson, and warp pulls in crypton and http2, and suddenly I have tons of transitive dependencies that take ages to build |
| 2026-03-29 21:12:36 | <tomsmeding> | I don't use aeson or json in any way, and I only need HTTP/1.1 so crypton and http2 are useless |
| 2026-03-29 21:13:40 | <tomsmeding> | and then I have a server that crashes and burns when I spam it with requests because warp decided that limiting accepts is not necessary |
| 2026-03-29 21:14:53 | <EvanR> | why does chronos or mustache even use aeson |
| 2026-03-29 21:15:06 | × | michalz quits (~michalz@185.246.207.203) (Remote host closed the connection) |
| 2026-03-29 21:15:10 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-03-29 21:15:28 | <tomsmeding> | chronos I think only for ToJSON/FromJSON instances |
| 2026-03-29 21:16:21 | <tomsmeding> | mustache the inverse, i.e. it has some functions taking ToJSON for convenience |
| 2026-03-29 21:16:26 | <tomsmeding> | I need none of this |
| 2026-03-29 21:16:31 | × | koala_man quits (~vidar@157.146.251.23.bc.googleusercontent.com) (Ping timeout: 264 seconds) |
| 2026-03-29 21:17:07 | <tomsmeding> | tempted to reimplement date <-> day-number handling from chronos, and simple GET-only HTTP/1.1 handling from scratch instead of warp |
| 2026-03-29 21:17:12 | <tomsmeding> | and nuke like 95% of my deps |
| 2026-03-29 21:17:14 | <EvanR> | breaking ToJSON FromJSON instances that aren't actually used in a library into a separate library, orphans I guess, sounds better in light of this |
| 2026-03-29 21:18:29 | <EvanR> | date <-> day-number ought to be not much copy pasta |
| 2026-03-29 21:18:34 | <tomsmeding> | yes |
| 2026-03-29 21:18:44 | <tomsmeding> | but then I still have aeson from mustache |
| 2026-03-29 21:18:58 | <tomsmeding> | so just nuking chronos helps naught |
| 2026-03-29 21:19:13 | <EvanR> | premature optimization! |
| 2026-03-29 21:20:01 | <EvanR> | this story suggests smaller more targeted libraries with fewer dependencies might be warranted |
| 2026-03-29 21:20:21 | <tomsmeding> | I've been looking for a haskell http server that is small and does simple stuff for ages |
| 2026-03-29 21:20:23 | <EvanR> | e.g. a thing that parses HTTP, but not necessarily every content type that exists |
| 2026-03-29 21:20:45 | <tomsmeding> | snap is the closest that I've found, but this time I wanted to try something different because snap is a bit weird sometimes |
| 2026-03-29 21:21:20 | <tomsmeding> | e.g. snap segfaulted when a request had an invalid Date: header because their C code didn't check errors (I fixed that) |
| 2026-03-29 21:21:57 | <EvanR> | OOF |
| 2026-03-29 21:23:03 | → | raincomplex_ joins (~rain@user/raincomplex) |
| 2026-03-29 21:23:09 | <tomsmeding> | https://github.com/snapframework/snap-core/pull/305 |
| 2026-03-29 21:23:13 | → | arandombit joins (~arandombi@2a02:2455:8656:7100:4dba:7f3:232c:4f01) |
| 2026-03-29 21:23:13 | × | arandombit quits (~arandombi@2a02:2455:8656:7100:4dba:7f3:232c:4f01) (Changing host) |
| 2026-03-29 21:23:13 | → | arandombit joins (~arandombi@user/arandombit) |
| 2026-03-29 21:23:19 | <tomsmeding> | not Date, If-Modified-Since apparently |
| 2026-03-29 21:23:39 | × | raincomplex quits (~rain@user/raincomplex) (Ping timeout: 268 seconds) |
| 2026-03-29 21:26:29 | × | abiss27 quits (~abiss27@user/abiss) (Quit: I'm off, Goodbye!) |
| 2026-03-29 21:26:47 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-03-29 21:27:04 | <mauke> | this is why I use a functional language like haskell: so I can FFI out to C for parsing and segfault on syntax errors |
| 2026-03-29 21:28:12 | <tomsmeding> | precisely |
| 2026-03-29 21:28:16 | × | arandombit quits (~arandombi@user/arandombit) (Ping timeout: 276 seconds) |
| 2026-03-29 21:31:09 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-03-29 21:31:30 | → | s00pcan joins (~s00pcan@24.73.63.94) |
| 2026-03-29 21:31:48 | × | s00pcan quits (~s00pcan@24.73.63.94) (Client Quit) |
| 2026-03-29 21:32:29 | → | s00pcan joins (~s00pcan@24.73.63.94) |
| 2026-03-29 21:38:51 | → | koala_man joins (~vidar@157.146.251.23.bc.googleusercontent.com) |
| 2026-03-29 21:40:30 | × | polykernel quits (~polykerne@user/polykernel) (Remote host closed the connection) |
| 2026-03-29 21:42:09 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
All times are in UTC.