Xref: utzoo comp.windows.news:338 comp.unix.wizards:6718
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.windows.news,comp.unix.wizards
Subject: Re: Use of select in NeWS.
Message-ID: <43423@sun.uucp>
Date: 27 Feb 88 10:21:14 GMT
References: <1376@vaxb.calgary.UUCP> <3189@bloom-beacon.MIT.EDU>
Sender: news@sun.uucp
Lines: 55

> It already has been; 4.3BSD has extended select in just the manner you
> described.
> 
> This was dealt with for X a long time ago; evidently the Sun people
> don't consider the 4.3 enhancements worth it..
> 
> main(){printf("%d\n",getdtablesize());} prints 64 on my system, and it
> can be configured higher than this.

Script started on Sat Feb 27 02:06:28 1988
gorodish$ cat foo.c
main()
{
	printf("%d\n", getdtablesize());
}
gorodish$ cc foo.c
gorodish$ ./a.out
64
gorodish$ cat /etc/motd
SunOS Release 4.0BETA2 (GORODISH) #204: Sat Feb 27 00:21:42 PST 1988
gorodish$ egrep FD_SET /usr/include/sys/types.h
 * FD_SETSIZE may be defined by the user, but the default here
#ifndef	FD_SETSIZE
#define	FD_SETSIZE	256
	fd_mask	fds_bits[howmany(FD_SETSIZE, NFDBITS)];
#define	FD_SET(n, p)	((p)->fds_bits[(n)/NFDBITS] |= (1 << ((n) % NFDBITS)))
gorodish$ 

script done on Sat Feb 27 02:06:41 1988

You were saying?  Evidently somebody here is making all sorts of assumptions
about what "the Sun people" do or don't consider worth it that simply don't
hold water.  (Upgrading SunOS to support >30 file descriptors would have been
non-trivial prior to 4.0, as file descriptor numbers were stuck in page table
entries when "mmap"ping frame buffers; the field in which they were stuck was 5
bits long, and 2 values were already taken (PG_FZERO and PG_FTEXT, from
4.2BSD), leaving 30 values behind.  It might have been possible to disallow
"mmap" on the larger descriptors, but I don't know that this wouldn't have
caused other problems.  SunOS 4.0 does "mmap" completely differently, so there
was no problem with increasing the size of the file table.)

BTW, I've run NeWS (some 1.1-flavored version) on my machine successfully, so I
presume this problem is fixed at least in the NeWS version they stick on the
machine from which I got it.  (A transformer is being replaced by PG&E sometime
tomorrow, so power has been shut down on the gateway from the network my
machine is on to the network the machine with the NeWS source is on; were this
not the case, I'd check the source to see what was done.)

> Perhaps they weren't _that_ concerned with portability, or else they
> wanted to make sure than NeWS ran better on their hardware than on
> anything else (so everyone buys their hardware to get the best
> version..).

Or maybe they were concerned with portability to systems that didn't have the
FD_SET stuff, which, for better or worse, includes SunOS releases 1.x through
3.x for the usual values of "x".