Hi, Clément Lassieur <[email protected]> skribis:
> Ludovic Courtès <[email protected]> writes: > >> Hello, >> >> Clément Lassieur <[email protected]> skribis: >> >>> I've noticed that narinfo baking is triggered by user requests when the >>> '--cache' option of 'guix publish' is used. It means that the first >>> user who will want it will get the 404 response and will have to build >>> it manually. (See guix/scripts/publish.scm, make-request-handler.) >> >> Note that the first request (404) returns with an expiry of 5mn instead >> of the default (much longer) expiry for “normal” 404s. >> >> We discussed this behavior at length back then and that seemed to me >> like a reasonable behavior for a service with many users: the first one >> gets 404 (or has to wait for 5 more minutes), but when there are enough >> users, it doesn’t matter much. > > But at least one user will complain, and if it's a small laptop building > Icecat... The way we’re doing things, there’s necessarily a delay (the build time plus some additional latency) between the moment and commit is pushed and the moment the corresponding package is built. Baking only adds a very small latency. >> This would be useful in reducing latency; the downside is that we’d bake >> lots of things, even possibly things that nobody ever needs. >> >> Thoughts? > > What about getting the first user to block until the baking is done? That’s generally not possible because HTTP is supposedly synchronous. Also, ‘guix publish’ has a bunch of worker threads that pick baking tasks from a queue. When the queue is empty and you asking for a substitute of sed, it will take seconds to bake it; but when the queue is already large and you’re asking for LibreOffice, it could take a few minutes. For the intended use case, which is a build farm with many users, optimizing for the first user makes little sense IMO. Thanks, Ludo’.
