From: Alejandro Colomar <alx@kernel.org>
To: Alexis Wilke <alexis@m2osw.com>
Cc: linux-man@vger.kernel.org, netdev@vger.kernel.org
Subject: re-listen(2) (was: <linux-man@vger.kernel.org>)
Date: Sun, 24 Mar 2024 21:15:18 +0100 [thread overview]
Message-ID: <ZgCJ3HtrAVViosBv@debian> (raw)
In-Reply-To: <59f9ef34-e9d9-41d5-8f97-2c070532a7d0@m2osw.com>
[-- Attachment #1: Type: text/plain, Size: 2223 bytes --]
Hi Alexis,
I've fixed the subject, and CC. You didn't send the mail to linux-man@.
I've also CCd netdev@, since they probably know better.
On Sun, Mar 24, 2024 at 10:16:02AM -0700, Alexis Wilke wrote:
> Hi Alejandro,
>
> I was looking at changing the "backlog" of a listen(2) call and could not
> find any documentation on how to do so.
>
> Clearly, it is possible under Linux simply by calling listen(2) again.
> However, the documentation does not mention the possibility.
Hmm, I see that POSIX doesn't specify either.
I didn't find it documented in linux.git/Documentation/ either (but I
only had a quick look; maybe it's there).
> We see on this stackoverflow post that it is how Nginx does it (see answer).
Nginx is known to abuse implementation details, and one shouldn't
necessarily trust what it does to be public API.
However, yeah, probably the kernel doesn't want to break Nginx, so maybe
we need to document it. I'm not sure if this is a violation of POSIX,
though. Maybe someone from netdev@ can confirm?
> https://stackoverflow.com/questions/64050281/can-backlog-value-that-is-passed-to-listen-call-be-modified-later-on-without-c
>
> I would propose to either add a new paragraph or add one sentence to the
> existing "backlog" paragraph to mention the ability.
>
> Here is the existing paragraph:
>
> The backlog argument defines the maximum length to which the
> queue of pending connections for sockfd may grow. If a connection
> request arrives when the queue is full, the client may receive an
> error
> with an indication of ECONNREFUSED or, if the underlying
> protocol supports retransmission, the request may be ignored so
> that a later reattempt at connection succeeds.
>
> What I propose is to add the following sentence to that paragraph:
>
> It is possible to call listen() again to change the the size of the
> backlog queue.
Let's see what netdev@ says.
Have a lovely night!
Alex
>
> Thank you.
> Alexis
>
--
<https://www.alejandro-colomar.es/>
Looking for a remote C programming job at the moment.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
parent reply other threads:[~2024-03-24 20:15 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <59f9ef34-e9d9-41d5-8f97-2c070532a7d0@m2osw.com>]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZgCJ3HtrAVViosBv@debian \
--to=alx@kernel.org \
--cc=alexis@m2osw.com \
--cc=linux-man@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/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 NNTP newsgroup(s).