kern/148581: [libc] fopen(3) fails with EMFILE if there are more than SHORT_MAX fds open

[Tobias Oberstein]

The following reply was made to PR kern/148581; it has been noted by GNATS.

From: Tobias Oberstein <tobias.oberstein at tavendo.de>
To: "bug-followup at FreeBSD.org" <bug-followup at FreeBSD.org>
Cc:  
Subject: Re: kern/148581: [libc] fopen(3) fails with EMFILE if there are
 more than SHORT_MAX fds open
Date: Mon, 14 Nov 2011 09:47:26 -0800

 Using Manish's test, I could verify that the bug is still present on both i=
 386 and amd64.
 
 FreeBSD XXXXX 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2=
 011     root at mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64
 
 FreeBSD XXXXX 8.2-RELEASE-p3 FreeBSD 8.2-RELEASE-p3 #0: Tue Sep 27 18:07:27=
  UTC 2011     root at i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERI=
 C  i386
 
 and even on FreeBSD 9 RC1 !!!!
 
 FreeBSD autobahnhub2 9.0-RC1 FreeBSD 9.0-RC1 #0: Tue Oct 18 18:30:38 UTC 20=
 11     root at obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386
 
 =3D=3D
 
 I'm doing a kqueue-based network service using Python/Twisted which will ha=
 ppily
 accept >50k TCP connections, but then bails out on Python open(<file>), sin=
 ce
 Python uses fopen(), and
 
 "It does not matter that these fds were not created by fopen."
 
 Python can't be recompiled to use open() (Posix) instead of fopen() (libc).
 
 Only the new Python IO does not use fopen() ... but this leads to other pro=
 blems (for me).
 
 =3D=3D
 
 So this won't be fixed even for FreeBSD 9?
 
 Please ...