Your flag #:blocking? #true would do a per-connection thread, which while implementing lack of blocking, is a stronger property than non-blocking. Also, (kernel-level) threads have some overhead, which is sub-optimal;
Instead of a flag, I propose defining a new ‘server-impl’ Web Server (Guile Reference Manual) (gnu.org) This impl could then spawn threads (or, more likely, do some thread pool things, presumably with some mitigations against ‘read one byte, wait N minutes’ DDOS attacks). Also, single-threaded does not imply blocking (assuming the implementation uses ‘select’ / ‘epoll’ / etc. -- I don’t know if Guile does that yet, might be worth checking). If the respond code writes to ports, some ‘(parameterize ((current-read-waiter ...) (current-write-waiter ...)) ...)’ + delimited continuations + O_NONBLOCK will be needed if the respond code writes to port. This, by the way, is already implemented by Guile-Fibers. I recommend using Guile-Fibers HTTP implementation or something based upon this (it has (relatively?) lightweight M:N user-level threads). I don’t recommend the default Fibers implementation, because it does ‘run-fibers’ and create threads on its own, which is really not its responsibility and as such makes it inconvenient to use when Fibers is used for other things as well. Instead, I am currently using fiberized.scm « server « web - gnunet-scheme.git - GNUnet client implementation in (Guile) Scheme (I don’t recall which changes I made). I’ve only used it for demo purposes so far, though. Best regards, Maxime Devos.
