| 23 Jun 2026 |
 raitobezarius | this will be burnout fuel | 15:50:05 |
| raitobezarius | the other approach we will take which is to remove the asyncness of curl in lix should unblock our ability to re-upgrade | 15:50:26 |
 zoë (@blokyk) | yeah that's fair enough | 15:50:29 |
| raitobezarius | then longer term, we remove curl | 15:50:34 |
 Sergei Zimmerman (xokdvium) | This CURL_WRITEFUNC_PAUSE all over again? | 16:16:25 |
| Sergei Zimmerman (xokdvium) | I do wonder how this does not blow up nix. We do it slightly differently and call curl_easy_pause(req, CURLPAUSE_RECV) inside the handler | 16:17:53 |
| Sergei Zimmerman (xokdvium) | (Which I found in some ancient mail thread to be the intended way to consume the data and not have it be delivered again) | 16:20:21 |
| Sergei Zimmerman (xokdvium) | But I'm not sure whether it's not causing the same kinds of problems | 16:21:23 |
 llakala | is curl vibecoding, or is this normal human stupidity? | 16:24:00 |
 K900 | curl is not vibecoding much | 16:25:49 |
| K900 | But their async API is significantly less battle tested | 16:25:55 |
| K900 | And getting async right in pure C is ... not very trivial | 16:26:08 |
| raitobezarius | you don't do async H2 afaik? | 17:41:54 |
| Sergei Zimmerman (xokdvium) | I mean, the consumer isn't an async stream, but the filetransfer does do h2 + pausing when streaming to multiple threads and doesn't do the old "block the whole curl thread when one transfer is slow" | 17:55:32 |
| Sergei Zimmerman (xokdvium) | The whole pausing/unpausing is quite similar | 17:56:35 |
| Sergei Zimmerman (xokdvium) | In terms of the only differences I can only see curl_easy_pause(req, CURLPAUSE_RECV) vs CURL_WRITEFUNC_PAUSE. Everything else is the same | 17:58:16 |
| Sergei Zimmerman (xokdvium) | * In terms of the only differences (curl API usage) I can only see curl_easy_pause(req, CURLPAUSE_RECV) vs CURL_WRITEFUNC_PAUSE. Everything else is the same | 17:59:10 |
| raitobezarius | yeah, this is what i mean by not doing async h2 | 18:22:39 |
| raitobezarius | i don't think we are hitting the same code paths in curl | 18:22:51 |
| Sergei Zimmerman (xokdvium) | Right, but that achieves effectively the same (modulo writing a bit larger than the buffer size) | 19:20:55 |
| Sergei Zimmerman (xokdvium) | So if what we are doing doesn’t anger libcurl as much (big if) then might be worth a shot | 19:21:36 |
| Sergei Zimmerman (xokdvium) | In reply to @raitobezarius:matrix.org
yeah, this is what i mean by not doing async h2 I’m still not getting what you mean. Pausing this way still does the pausing of a single stream on the multiplexes h2 connection according to the docs | 19:31:54 |
| Sergei Zimmerman (xokdvium) | In reply to @raitobezarius:matrix.org
yeah, this is what i mean by not doing async h2 * I’m still not getting what you mean. Pausing this way still does the pausing of a single stream on the multiplexed h2 connection according to the docs | 19:32:20 |
|  isabel changed their profile picture. | 19:51:18 |
| isabel changed their profile picture. | 19:51:24 |
| raitobezarius | i mean precisely that you are not using return values for pausing transfers | 19:53:42 |
| raitobezarius | it seems so | 19:54:59 |
| raitobezarius | except that curl disagrees at the impl level | 19:55:05 |
| raitobezarius | given how different this is in production | 19:55:10 |
| raitobezarius | and it's extremely frustrating that the two methods seems to differ only by "one is more respectful of buffer sizes" while completely failing atm | 19:55:57 |
