From: Maxime Devos <maximedevos@telenet.be>
To: Ryan Raymond <rjraymond@oakland.edu>,
"guile-devel@gnu.org" <guile-devel@gnu.org>
Subject: RE: Non-blocking web server
Date: Mon, 25 Mar 2024 11:44:42 +0100 [thread overview]
Message-ID: <20240325114442.2ykh2C00A40GHUc01ykhQg@laurent.telenet-ops.be> (raw)
In-Reply-To: <CAGvJ-HQQZ++7g36ti_X2TB_1iMMDoL70CNzMstwZAu+QZ53tmQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1625 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 4271 bytes --]
prev parent reply other threads:[~2024-03-25 10:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-24 19:41 Non-blocking web server Ryan Raymond
2024-03-25 5:31 ` tomas
2024-03-25 9:24 ` Nala Ginrut
2024-03-25 10:44 ` Maxime Devos [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240325114442.2ykh2C00A40GHUc01ykhQg@laurent.telenet-ops.be \
--to=maximedevos@telenet.be \
--cc=guile-devel@gnu.org \
--cc=rjraymond@oakland.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).