X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:subject:message-id:reply-to :references:mime-version:content-type:in-reply-to; q=dns; s= default; b=CMZXu/DQR49SPgROn7bRlf4NE0NCJ/2D3WL/0AaQ6jHTJ5R9SFqpT WQA6TK/KzCoibIuo6io/PfZ0+Q0/zEGwhnq9QXzmQ00a5mDbqoMm6ZrSCyNQfvHx PMGVdXnzcEGjD2s1Ps2XwwK+b8i8R6VKXt4GkGbWY0fkyVh1ZfqFbM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:subject:message-id:reply-to :references:mime-version:content-type:in-reply-to; s=default; bh=a4EXt8RFioCuYx8OOqlR2G2gWzs=; b=cpd9xMKuUG2xbRZ/WA/ZO2ZDnWfI RlUgBzvZzXs3YQj7mw04HdBGnIk4pvGWahSRr6fohg66WMzhqoTTVobg6gob7fHp X5xbOekzjqL7hvI3SD/qWadAee7ddOJg1t6mlmhvnO3P0Wv3D6ms76QCeTcY38mz hvuNNr2J1YjpAfA= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-100.1 required=5.0 tests=AWL,BAYES_05,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_BRBL_LASTEXT,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=dates, pose, init_events, enobuf X-HELO: drew.franken.de Date: Fri, 3 Nov 2017 21:36:14 +0100 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: Bug(s) with creating large numbers of sockets Message-ID: <20171103203614.GB18070@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IS0zKkzwUGydFO0o" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Erik, why didn't you send this to cygwin-patches? Not much of a problem, just wondering... On Nov 3 15:39, Erik Bray wrote: > [...] > After some playing around I found that I could make up to exactly 1365 > sockets and use them without error. At 1366 I get the error. A very > strange and arbitrary number. It turns out this is limited in Cygwin > by the array in fhandler_socket.cc: >=20 > 496 /* Maximum number of concurrently opened sockets from all Cygwin pro= cesses > 497 per session. Note that shared sockets (through dup/fork/exec) are > 498 counted as one socket. */ > 499 #define NUM_SOCKS (32768 / sizeof (wsa_event)) > ... > 510 static wsa_event wsa_events[NUM_SOCKS] __attribute__((section > (".cygwin_dll _common"), shared)); >=20 > This choice for NUM_SOCKS is still seemingly small and pretty > arbitrary, but at least it's a choice, and probably well-motivated. This obviously dates back to pre-64 bit times. The idea at the time was that the .cygwin_dll_common section fits into a single 64K allocation chunk. Every section takes at least this 64K chunk, so we get away with only one of them for this section. Turns out, shared sections have a few issues so we even reduced the usage and only kept stuff in which doesn't pose much of a problem. Right now .cygwin_dll_common has a size of 0x8220 / 0x8200 of a max. of 0x10000, so we have still lots of room and nothing really in need of using a shared section. > However, I think it's a problem that it's defined in terms of > sizeof(wsa_event). On 32-bit Cygwin this is 16, so NUM_SOCKS is 2048 > (a less strange number), whereas on 64-bit Cygwin sizeof(wsa_event) =3D= =3D > 24 (due to sizeof(long) =3D=3D 8, plus alignment), so we are limited > to...1365 sockets. >=20 > If we have to set a limit I would just hard-code it to 2048 exactly. > I understand that the overhead associated with sockets in Cygwin > probably limits us from having 10s of thousands (much less millions) > and that's OK--I'm not trying to run some kind of C10K challenge on > Cygwin :) We only need another 0x220 bytes so we have a theoretical 0xfde0 / 64992 bytes or 2708 sockets for wsa_events on 64 bit. So, yeah, I think you're right, 2048 is good number. As I wrote in the comment preceeding NUM_SOCKS, these are 2048 independent sockets per user session in parallel. Sockets created by dup or shared via fork/exec only take one slot anyway. 2048 independent sockets per user session should really suffice outside of testcases. > The other problem, then, seems to be a bug in > fhandler_socket::init_events(). It doesn't check the return value of > search_wsa_event_slot(), which returns NULL if the wsa_events array is > full (and the socket is not a shared socket). There's not a great > choice here for error code, but setting ENOBUF seems like the best > option. Yep, bug. Thanks for catching. > Please see attached patch. Can you please send it to cygwin-patches with a bit of additional comment (just a couple of words) why we choose 2048 here? Thanks, Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --IS0zKkzwUGydFO0o Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJZ/NM+AAoJEPU2Bp2uRE+gVNwP/ixPRgtdJm+PQOu+/U6lbi/c K87zgwk7yXu5FDkDInJ7ijEOMzQL/6BepM5gtBcFWlBNt3wg8wLPvN0fbVGU6DxE bQZv9SwshFY7rtCWk6VHuj57PwumPcLTGvmhHvDtaDOpC7/hb8DrLWui5u6hK8L+ UeYlWnyhhhHUSfsuAdi33NIBsBBYtFtgIEfYzXPog68Txl2RTaxbyBNaqenKdPK6 STePXeMIqe8Ju3y+N8yAiWE+iDkpddCPQP6ppzKYaaWaNaZuVaaCgqteECeD050V I2rsQ3AXvFpUo0NIz98cLgp8JPG+7raEyVr48WhH0jzUJgvQ6Jurg+LvyUHihBx5 /aD8RK3w62oyor6yIyHL285jb/K5tF3kVnUq9YV2IRH98kNRlE9rG0Jo0AKhxe7C WGf0KxaoiV3hAjIqfoe0Ivv8ySfiuqwLq17YevwhuwbTY0bpO7Ah81A7C2nzdMpb MRzjPmwEk5HQXAMiQ7cH2UO4zUQFtCJqWlOeVX+HbYYL1Igi5VPWkqZnMFotqrpi FqtuY9Dijw3BJn1HCGtlNCMM64MXF5gPOvO4srhe/hEbHIUuyfBmaYUi6JRWHR7w eAVROViZzJiUxkzWoryXKv47XyYszYUz8DEDNxB/DhJwZGRbrIAq2lKXLKmvH0IK /ELdg01aK/rkcvjWqD6o =iJqD -----END PGP SIGNATURE----- --IS0zKkzwUGydFO0o--