From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Maxime Devos Newsgroups: gmane.lisp.guile.devel Subject: RE: Non-blocking web server Date: Mon, 25 Mar 2024 11:44:42 +0100 Message-ID: <20240325114442.2ykh2C00A40GHUc01ykhQg@laurent.telenet-ops.be> References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_87ADA88B-1981-4701-9E82-9281A9562F6E_" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29687"; mail-complaints-to="usenet@ciao.gmane.io" To: Ryan Raymond , "guile-devel@gnu.org" Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Mon Mar 25 11:45:00 2024 Return-path: Envelope-to: guile-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rohp5-0007OY-Uy for guile-devel@m.gmane-mx.org; Mon, 25 Mar 2024 11:45:00 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rohox-0004Ed-5b; Mon, 25 Mar 2024 06:44:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rohov-0004Dp-AS for guile-devel@gnu.org; Mon, 25 Mar 2024 06:44:49 -0400 Original-Received: from laurent.telenet-ops.be ([2a02:1800:110:4::f00:19]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rohos-0000tT-Pm for guile-devel@gnu.org; Mon, 25 Mar 2024 06:44:49 -0400 Original-Received: from [IPv6:2a02:1808:88:6ede:39c4:cdb2:2cff:c7bc] ([IPv6:2a02:1808:88:6ede:39c4:cdb2:2cff:c7bc]) by laurent.telenet-ops.be with bizsmtp id 2ykh2C00A40GHUc01ykhQg; Mon, 25 Mar 2024 11:44:42 +0100 Importance: normal X-Priority: 3 In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=telenet.be; s=r24; t=1711363482; bh=8Z1q+iv0+q8RkDCAuTMfPgZTiyjVOknnXDNQ6eyUyJo=; h=To:From:Subject:Date:In-Reply-To:References; b=HiNDX5bMD2PVHNsB6CCBRbMreapJrUdac4dp3bx3AKvzJsgKIS/Kr1VDU3qc0Iutt G/jPBJfic7Hc64abDy9z32OfT8DLaeCp4RuuIDLl843GhiM/RHrpB8DSaBLXhifQoF HHHPYlWwaslFQNYiMWFawniuWMfWTfU/y6DpodGmFImSQ0paH3sJ1DdalAW6oT/+EE VjLOZBdWpJqRNSKlgx6GKR2u8Kmsh3XaLcrXU7IKtB1I7m/7y/yrkNeGhOrJUTbc6f aH8WODpYM2se38ymynsh6bfG9ESrIZpdaolXFIuQj8zFnwrByAxjv6snA7FcJEFMA2 qpjUTaIfHitDw== Received-SPF: pass client-ip=2a02:1800:110:4::f00:19; envelope-from=maximedevos@telenet.be; helo=laurent.telenet-ops.be X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.devel:22371 Archived-At: --_87ADA88B-1981-4701-9E82-9281A9562F6E_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your flag #:blocking? #true would do a per-connection thread, which while i= mplementing lack of blocking, is a stronger property than non-blocking. Als= o, (kernel-level) threads have some overhead, which is sub-optimal; Instead of a flag, I propose defining a new =E2=80=98server-impl=E2=80=99 Web Server (Guile Reference Manual) (gnu.org) This impl could then spawn threads (or, more likely, do some thread pool th= ings, presumably with some mitigations against =E2=80=98read one byte, wait= N minutes=E2=80=99 DDOS attacks). Also, single-threaded does not imply blocking (assuming the implementation = uses =E2=80=98select=E2=80=99 / =E2=80=98epoll=E2=80=99 / etc. -- I don=E2= =80=99t know if Guile does that yet, might be worth checking). =20 If the respond code writes to ports, some =E2=80=98(parameterize ((current-= read-waiter ...) (current-write-waiter ...)) ...)=E2=80=99 + delimited cont= inuations + 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 (rel= atively?) lightweight M:N user-level threads). I don=E2=80=99t recommend the default Fibers implementation, because it doe= s =E2=80=98run-fibers=E2=80=99 and create threads on its own, which is real= ly not its responsibility and as such makes it inconvenient to use when Fib= ers is used for other things as well. Instead, I am currently using fiberized.scm =C2=AB server =C2=AB web - gnunet-scheme.git - GNUnet client = implementation in (Guile) Scheme (I don=E2=80=99t recall which changes I made). I=E2=80=99ve only used it fo= r demo purposes so far, though. Best regards, Maxime Devos. --_87ADA88B-1981-4701-9E82-9281A9562F6E_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

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-op= timal;

&n= bsp;

Instead of a f= lag, I propose defining a new =E2=80=98server-impl=E2=80=99

 

<= p class=3DMsoNormal>Web Server (Guile Reference Man= ual) (gnu.org)

 

This impl could then spawn threads (or, more likel= y, do some thread pool things, presumably with some mitigations against =E2= =80=98read one byte, wait N minutes=E2=80=99 DDOS attacks).

 

<= p class=3DMsoNormal>Also, single-threaded does not imply= blocking (assuming the implementation uses =E2=80=98select=E2=80=99 / =E2= =80=98epoll=E2=80=99 / etc. -- I don=E2=80=99t know if Guile does that yet,= might be worth checking).=C2=A0

 

If the respond code writes to ports, some =E2=80=98(parameteri= ze ((current-read-waiter ...) (current-write-waiter ...)) ...)=E2=80=99 + d= elimited continuations + O_NONBLOCK will be needed if the respond code writ= es to port.

 

This, by = the way, is already implemented by Guile-Fibers. I recommend using Guile-Fi= bers HTTP implementation or something based upon this (it has (relatively?)= lightweight M:N user-level threads).

 

I don=E2=80=99t recommend the default Fibers implementatio= n, because it does =E2=80=98run-fibers=E2=80=99 and create threads on its o= wn, which is really not its responsibility and as such makes it inconvenien= t to use when Fibers is used for other things as well.

 

Instead, I am currently using<= /span>

 <= /p>

fiberized.scm =C2=AB server =C2=AB web - g= nunet-scheme.git - GNUnet client implementation in (Guile) Scheme<= /o:p>

 

(I don=E2=80=99t recall which cha= nges I made). I=E2=80=99ve only used it for demo purposes so far, though.

 

Best regards,

Maxime Devos.

= --_87ADA88B-1981-4701-9E82-9281A9562F6E_--