Rich Gray wrote:

> This worked. I wonder how much problem the lack of a timeout
> on connect is? Doesn't the connect() call have its own inherent
> timeout?

On Solaris this timeout is determined by the kernel parameter
'tcp_ip_abort_cinterval'. If memory serves me, you can find it
with something like this

  % ndd -get /dev/tcp tcp_ip_abort_cinterval

This parameter can be altered, but only globally (that is, it
affects all processes).

> Some interesting issues here. How far does an application
> go to be portable?? Our use of this old sparc system is
> as a development platform. We have found that it is safer
> to compile on old systems and trust that newer systems will
> have good backward compatibility than to have new systems and
> depend on older systems to have forward compatibility. Of

At work we do the same, except we use Solaris 2.5.1, rather than
Solaris 2.4 (apart from you, I don't know anybody who still uses
2.4 ;)

> Patch-ID# 101945-63
[...]
> 1171478 socket recv() calls fail with EINVAL due to bad fix in 5.4

Looks promising.

> This is also an interesting ramification for autoconfigure
> applications. If the goal is to compile a binary for distribution,
> it should be tuned as minimally as possible to the compile platform
> and perhaps make some runtime decisions instead compile time, based
> on OS version (if that can be sensed reasonably...)

Indeed. It may be possible to make a run-time workaround by setting
the socket to blocking mode if read() returns EINVAL, and then retry
the read.

However, we should be aware that EINVAL is a valid return code
according to the Single Unix Specification, version 3 (version 2 does
not cover the read/recv functions, but systems implementing that
standard may very well support the standardized EINVAL behaviour)
So, the workaround should probably be guarded by something like this

  #if defined(sun) && defined(_SVR4) /* Solaris */
  # if !defined(_XOPEN_VERSION) || (_XOPEN_VERSION < 500) /* UNIX95 or earlier
*/
  /* Workaround goes here */
  # endif
  #endif
Received on 2002-04-30