radford@calgary.UUCP (Radford Neal) (02/23/88)
The portable NeWS source code (1.0) contains the following bit
of programming:
int readfds, writefds, exceptfds;
...
max_fds = getdtablesize();
...
select(max_fds, &readfds, &writefds, &exceptds, timeout);
I think it is worth pointing out that this is *WRONG*. The correct
approach is to pass 32 as the first parameter of select, maybe via
a constant definition.
The reason for the first parameter is to specify the size of the
bit vectors whose addresses are passed as the 2nd, 3rd, and 4th
parameters. These bit vectors are clearly 32 bits in size.
The above code will break horribly if UNIX is ever extended to
allow more than 32 file descriptors. (Select in this case would be
able to take pointers to arrays of ints.) Passing an explicit 32 as
the first parameter will continue to work as long as the program
isn't actualy using more than 32 files.
Radford Neal
The University of Calgarywesommer@athena.mit.edu (William Sommerfeld) (02/24/88)
In article <1376@vaxb.calgary.UUCP> radford@calgary.UUCP (Radford Neal) writes: >The above code will break horribly if UNIX is ever extended to >allow more than 32 file descriptors. 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. 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..). - Bill
bzs@bu-cs.BU.EDU (Barry Shein) (02/25/88)
>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..). > > - Bill Yeah Bill, great plot heh! It would probably take 10 or 15 minutes to track down the select() bug thereby crushing the competition by forcing a late release...And I suppose Athena puts all those NULL pointer bugs into X-windows as a plot to force people to buy Vaxes! C'mon, I can't believe you said this, do you really believe this is true? -Barry Shein, Boston University
chapman@eris (Brent Chapman) (02/25/88)
In article <20164@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes:
#
#>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..).
#Yeah Bill, great plot heh! It would probably take 10 or 15 minutes to
#track down the select() bug thereby crushing the competition by
#forcing a late release...And I suppose Athena puts all those NULL
#pointer bugs into X-windows as a plot to force people to buy Vaxes!
#
#C'mon, I can't believe you said this, do you really believe this is
#true?
Well, Sun _does_ have two different versions of NeWS, according to the
instructors from Sun at the NeWS tutorial at the Phoenix USENIX last
summer. There's the fast, tuned, Sun-only version that is what Sun
distributes binaries from, then there is the slower, portable version
that they will sell source for to other vendors.
-Brent
--
Brent Chapman
chapman@mica.berkeley.edu or ucbvax!mica!chapmandavid@elroy.Jpl.Nasa.Gov (David Robinson) (02/25/88)
In article <7171@agate.BERKELEY.EDU>, chapman@eris (Brent Chapman) writes: > In article <20164@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: > # > #>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..). > > #Yeah Bill, great plot heh! It would probably take 10 or 15 minutes to > #track down the select() bug thereby crushing the competition by > #forcing a late release...And I suppose Athena puts all those NULL > #pointer bugs into X-windows as a plot to force people to buy Vaxes! > # > #C'mon, I can't believe you said this, do you really believe this is > #true? > > Well, Sun _does_ have two different versions of NeWS, according to the > instructors from Sun at the NeWS tutorial at the Phoenix USENIX last > summer. There's the fast, tuned, Sun-only version that is what Sun > distributes binaries from, then there is the slower, portable version > that they will sell source for to other vendors. Huh? I think you are a bit off here. Looking in our NeWS 1.0 source directory we have a REF directory and a SUN directory. The SUN directory contains the EXACT source that Sun generates the binaries from. The REF directory contains the "portable" reference code that makes initial ports easier. For Example, if you have a device that you can memory map it has the routines that does all the screen operations into memory. It is slow of course but allows you to quickly get a port going. The Sun code is highly tuned for the Sun pixrect libraries and in the REF directory they provide a method to emulate pixrects on other machines. If your were to seriously port NeWS to a completely new display device you would probably start with the REF code and improve on it using the example of Sun's native port. I doubt if Sun is out to force all other NeWS servers to be slow! If you have a "smart" display device with a built in CPU, the Masscomp "Aurora" comes to mind, you could built a much faster NeWS server than Sun could with their "dumb" displays. -- David Robinson elroy!david@csvax.caltech.edu ARPA david@elroy.jpl.nasa.gov ARPA {cit-vax,ames}!elroy!david UUCP Disclaimer: No one listens to me anyway!
pierson@encore.UUCP (Dan Pierson) (02/26/88)
In article <7171@agate.BERKELEY.EDU> chapman@eris.UUCP (Brent Chapman) writes: >Well, Sun _does_ have two different versions of NeWS, according to the >instructors from Sun at the NeWS tutorial at the Phoenix USENIX last >summer. There's the fast, tuned, Sun-only version that is what Sun >distributes binaries from, then there is the slower, portable version >that they will sell source for to other vendors. This does make some sense. A Sun explained it at a NeWS tutorial last fall, the fast, tuned, Sun-only version is fast and tuned because it's built on top of SunWindows primitives which are neither portable nor available in source form to competitors. The slower, portable version only requires a Sun frame buffer. It certainly makes a lot of engineering sense for Sun to want to reuse their existing technology in a Sun-only product. It also make sense for them not to spend a lot of time and money creating a high-performance portable *sample* server. After all, there is not much point in using the slow, sample server on a Sun when the fast server is available and cheap. A highly optimized sample Sun server might be *less* useful to porters than the existing sample because the optimizations would probably add a good deal of non-portable complexity to the server code. -- In real life: Dan Pierson, Encore Computer Corporation, Research UUCP: {talcott,linus,necis,decvax,ihnp4}!encore!pierson Internet: pierson@multimax.arpa
msc@ramoth.SGI.COM (Mark Callow) (02/27/88)
In article <3189@bloom-beacon.MIT.EDU>, wesommer@athena.mit.edu (William Sommerfeld) writes: > > 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..). > > - Bill Our getdtablesize() returns 100. The select code in NeWS took all of half-an-hour to change. It would have been nice if we hadn't had to change it but it appears that the Sun OS hadn't yet learned about the 4.3 enhancements when NeWS 1.0 was written. Given that, I'd say the reality was the reverse of your statement. NeWS may run better on other vendors hardware. -- From the TARDIS of Mark Callow msc@sgi.sgi.com, ...{ames,decwrl,sun}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its content."
msc@ramoth.SGI.COM (Mark Callow) (02/27/88)
In article <7171@agate.BERKELEY.EDU>, chapman@eris (Brent Chapman) writes: > Well, Sun _does_ have two different versions of NeWS, according to the > instructors from Sun at the NeWS tutorial at the Phoenix USENIX last > summer. There's the fast, tuned, Sun-only version that is what Sun > distributes binaries from, then there is the slower, portable version > that they will sell source for to other vendors. > > -- The source licensee receives the source for both versions. The difference lies in the underlying pixrect graphics support and in the OS interfaces. The licensee is free to choose the most appropriate version for his hardware. The pixrect changes are mostly for portability. Ifdef's allow it to work on both LITTLEENDIAN and BIGENDIAN machines. The left hand casts are gone. The SUN version also relies on some tricks available with the Sun compiler/assembler combo that allow assembler functions to be put in line wherever they are called instead of making function calls. The speed difference between the 2 versions is small. -- From the TARDIS of Mark Callow msc@sgi.sgi.com, ...{ames,decwrl,sun}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its content."
guy@gorodish.Sun.COM (Guy Harris) (02/27/88)
> 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".