From: jrs@world.std.com (Rick Sladkey) Subject: Re: new select Date: 14 Nov 1992 03:43:56 GMT
>>>>> On 13 Nov 92 08:57:12 GMT, hedrick@geneva.rutgers.edu (Charles
>>>>> Hedrick) said:
Charles> I haven't tried 0.98 yet, but I'm surprised at the reports of
Charles> problems with 0.98pl4 caused by increasing the number of open
Charles> files. The select interface was designed so that you could
Charles> increase the number of open files without messing up old
Charles> programs. That's why select takes the number of file
Charles> descriptions as an argument. Even if the kernel now supports
Charles> 256 files, if a program calls select with 32 or less, why
Charles> doesn't it behave in the old way? If such programs really
Charles> break, it's going to cause all kinds of compatibility
Charles> problems. Is it really necessary?
If a program calls select with 32 or less, it does behave in the old
way. The problem is with programs which called select with greater
than 32. For example, GNU Emacs arbitrarily calls select with 64 when
the macro FD_SET is defined. This works when compiled with the old
headers and used with the old kernel or when compiled with the new
headers and used with the new or the old kernel. However, it does not
work when compiled with the old headers and used with the new kernel.
The bottom line is that very few programs break and those that do were
using select in an risky fashion. The really ironic thing is that
programs which safely used getdtablesize() will get the "new" size
when the next version of the shared libraries come out and thus would
be potential candidates for breaking. Fortunately, the old entry
point for select will compensate for this and trim the number of
descriptors back to 32. Newly compiled programs will get a new select
entry point that is safe for any value up to 256.