As the author told someone who passed it on to me, DP does
not "run" under Solaris 2.x. The reality is it does, but some
things don't work.
First, there is a bug in distribObj.tcl that a colleague here
at AT&T found. Here's the diff:
*** distribObj.tcl.orig Mon Jan 23 13:57:56 1995
--- distribObj.tcl Mon Jan 23 13:58:21 1995
***************
*** 170,176 ****
incr objInfo($obj,$proc) -1
if {$objInfo($obj,$proc) == 0} {
dp_RDO $proc dp_DeleteRemoteObject $obj
! set objInfo($obj) [ldelete $objInfo($obj,clients) $proc];
unset objInfo($obj,$proc)
dp_atclose $proc delete "unset objInfo($obj,$proc)"
}
--- 170,176 ----
incr objInfo($obj,$proc) -1
if {$objInfo($obj,$proc) == 0} {
dp_RDO $proc dp_DeleteRemoteObject $obj
! set objInfo($obj,clients) [ldelete $objInfo($obj,clients) $proc];
unset objInfo($obj,$proc)
dp_atclose $proc delete "unset objInfo($obj,$proc)"
}
Second, out of the box, with this diff applied, DP will pass
these tests on Solaris: auth, filehandler, oo, & rpc.
The connect test hangs at 2.1.
The udp test quits at 3.1 after several errors in the 2.x series.
These errors appear to be linked to the connect() system call.
Can anyone shed any light on the differences in connect() going
from Solaris 1.1 (SunOS 4.1.3) to Solaris 2?
Third, if you limit your networking to the STREAMS based
protocols, which I would think most people would do,
DP works fine under Solaris 2. Unless...
Fourth, you're running Solaris 2.4, which apparently has a bug
in select()/poll(). This caused various troubles in distributed
objects when communicating between different machines across
the network. My investigation points to the select() call
in DP during the Tdp-PacketReceive() routine. My results are
backed up by about three weeks of testing with a software
package that worked under Solaris 2.3 but now likes to hang
under Solaris 2.4.
Fifth, I'm trying to verify that Sun is working on or has a
patch for the select()/poll() bug; and I'm going to try
to get my hands on it. I've heard it would be included
in the kernel jumbo patch sometime soon.
Sixth, thanks to all who fed me info...I'll continue
to summarize as needs dictate.
-- | Jim VandeVegt | Computer Systems Engineer |"I refuse to be victimized| | AT&T Network Systems | jmv@ohgua.att.com | by notions of virtuous | | Omaha Works | vandevek@csealumni.unl.edu| behavior"--Calvin | |-------------#include <disclaimer.h>--------------|==========================|
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:17 CDT