Maxime Devos <maximede...@telenet.be> skribis: > Ludovic Courtès schreef op wo 23-03-2022 om 23:36 [+0100]: > Thoughts? > > From service.scm: > >> + (define (sleep* n) >> + ;; In general we want to use (@ (fibers) sleep) to yield to the >> scheduler. >> + ;; However, this code might be non-suspendable--e.g., if the user calls >> + ;; the 'start' method right from their config file, which is loaded with >> + ;; 'primitive-load', which is a continuation barrier. Thus, this >> variant >> + ;; checks whether it can suspend and picks the right 'sleep'. >> + (if (yield-current-task) >> + (begin >> + (set! sleep* (@ (fibers) sleep)) >> + (sleep n)) >> + (begin >> + (set! sleep* (@ (guile) sleep)) >> + ((@ (guile) sleep) n)))) > > Instead of working around this limitation of Fiber's 'sleep', > why not modify Fiber's sleep to detect if it is from a suspendable > context or not, and depending on that, use Guile's sleep/usleep or > the perform-operation+sleep-operation?
The short answer is that I want to get that done and not rely on an unreleased version of Fibers. The hack above uses the public interface; it’s not pretty, but I think it’s okay. Longer-term, maybe we could change Fibers’ ‘sleep’ as you suggest. Whether it’s a good idea is debatable: one could argue that Fibers’ ‘sleep’ is meant to be called from a fiber (suspendable). Ludo’.
