Subject: Re: Which is "better" Sun Sparc with Solaris or 486/586 with Unixware

From: [email-masked] (Terry Lambert)
Date: 8 Mar 1994 22:14:06 GMT

In article <[email-masked]> [email-masked] (Jeff Kopmanis) writes:
>And be sure to guage the anti-Solaris flaming you'll
>no-doubt see after this, for most of it is hollow, unsubstantiated drivel. 
>I've never experienced any of the problems that people complain about when
>moving from 4.1.3 to Solaris.

I wasn't going to say anything until I read the last two sentences.

1)	The system clock resoloution on Solaris is 10ms; this is useless
	for anything but statistical profiling, and statistical profiling
	is useless if you are trying to test cache efficacy.

2)	The system interval timer resoloution is 10ms.  Not only is this
	way too low, it is in violation of SVID.  SVID, Third edition,
	Volume III clearly states:

	In: gettimeofday(RT_OS):

	[...] The resoloution of the system clock is hardware dependent;
	the time may be updated continuously, or in ticks.

	And in: getitimer(RT_OS):

	[...] Time values smaller than resoloution of the system clock
	are rounded up to this resoloution.

	PLEASE NOTE: THIS SPECIFIES INTERVAL TIMER RESOLOUTIONS ARE TO
	BE MAINTAINED AT THE RESOLOUTION OF THE SYSTEM CLOCK -- *NOT*
	THE UPDATE RESOLOUTION OF THE SYSTEM CLOCK AFTER ROUNDING FOR
	REPORTING BY gettimeofday(RT_OS).

3)	Statically linked binaries from 4.1.3 will *NOT* run on Solaris
	if they call the select(2) system call (among others).  The
	error return will be ENOSYS, since select(*3*) is a library
	routine in Solaris, and thus backward compatability is available
	only to dynamically linked programs!

4)	Dynamically linked programs using select(2-now-3) will lose the
	ability to specify timer resolutions smaller than 10ms; this is
	because select(3) is implemented using the poll(2) system call,
	which has a maximum resoloution of 10ms (can you say "broken
	X programs"?).

5)	Solaris incorrectly rounds select(3) timeout values less than
	10ms to 0ms (effecting a selelct-nomenclature-poll), instead of
	rounding up to the minimum delay value; if it must do the wrong
	thing and round (the documentation of select(3) makes no claims
	of reduced resoloution below that of the timeval struct, that is,
	1uS), at least it should round up for non-0 values (can you say
	"really, really broken X programs"?).

Of course there are numerous other instances of brokenness in Solaris,
which I have noted in other postings elsewhere, such as the inability to
use _POSIX_SOURCE preprocesser definition in conjunction with some system
include file when writing device drivers, but these are the most *glaring*
screw-ups that keep me runnung 4.1.3, which at least has the "it works"
option compiled into the kernel.

					Terry Lambert
					[email-masked]
---
Any opinions in this posting are my own and not those of my present
or previous employers.

---

From: [email-masked] (Casper H.S. Dik)
Date: 9 Mar 1994 10:24:22 GMT

>	is useless if you are trying to test cache efficacy.

This is true in SunOS as well.

>	REPORTING BY gettimeofday(RT_OS).

You're picking nits, I think.  Is gettimeofday() the system clock?
Or is the system clock incremented with ticks and does gettimeofday
return a more precise value?

>	only to dynamically linked programs!

Works in 2.3.

>	which has a maximum resoloution of 10ms (can you say "broken

Select has always had a 10ms resolution.  A program that runs 1000 selects
with a timeout of less than 10ms (e.g., one microsecond) will take
10 seconds to complete. (I just tried it)

>	"really, really broken X programs"?).

Ah, now I get your point.  select(3) IS broken.  But 4 & 5 are
the same point, in that case.  If you specify a timer resolution of
less than 1ms, it is rounded to 0.  (I.e., a timeout of 0) instead
of the expected 10ms, the minimum timeout in SunOS and Solaris.

>option compiled into the kernel.

The kernel isn't a POSIX conformant environment.  I'm not suprised that
defining _POSIX_SOURCE breaks compiling for the kernel.
E.g., the kernel has totally different understanding of signals than
the outside world.

It is bad that there is no way to specify ``strict ANSI + all of Suns
extensions even if they conflict with the standard''.

[ You may say, ``well I don't want extensions that conflict''.
That's what you get now:  all extensions in header files defined
in the ANSI standard conflict with that standard, with only a handful
of exception.  All non-ANSI types and functions in the name space usable
by the user (and that's most of them) cannot be defined in a strict ANSI
mode, because it would cause the compilation of strictly conforming
applications to fail.

Casper