ken@gvax.cs.cornell.edu (Ken Birman) (07/27/89)
We are pleased to announce that ISIS V1.2 has survived its BETA
test period and is now apparently solid. If you have been using
ISIS V1.0 or V1.1, we no longer plan to support those versions of
the system, and encourage you to switch to this latest version as
soon as possible. If you have been using a copy of ISIS V1.2
obtained from us at any time prior to this posting, please copy
the latest version over to your system as soon as you get a chance
and recompile/relink using it.
My group is firmly committed to supporting ISIS V1.2. If you report
a problem (mail to isis-bugs@cs.cornell.edu, or to me) we will fix
it, without charge, and as quickly as we can. If you don't report
problems, however, don't expect them to go away on their own.
We have compiled and tested this version at Cornell on SUN OS 4.0,
HPUX, MACH (release 0.9 on the NEXT computer), uVAX workstations and
the DEC 3100/MIPS machine.
Some common observations from the beta test group that may be of
general interest:
1. Under HPUX, we have seen a tendency of the HP scheduler (in their
version of UNIX) to act a bit "batchy", which can cause funny looking
pauses if you run the grid display program with several copies on
one machine. These seems unrelated to anything that ISIS is doing.
2. The lmgr program now terminates by exiting shortly after startup.
This is normal.
3. Because ISIS redefines "exit()" as "_exit()" under SUN LWP, flushing
of IO channels may not occur in SUN programs that call exit to terminate.
We recommend that you call "pod_exit" if this causes problems. For
technical reasons, it appears to be a bad idea for ISIS to simply
redefine "exit" as "pod_exit" directly under LWP.
4. The LUCID lisp port is now included, but consider this an ALPHA release.
Comments/problems to rcbc@cs.cornell.edu. The ALLEGRO lisp port is solid.
5. Be careful when recoding ``old'' programs to call isis_accept_events().
People seem to be confused about whether to specify ISIS_BLOCK or 0
in this call. The normal mode is to specify ISIS_BLOCK, in which case
ISIS will wait (if necessary) until a message arrives or something
else happens that might change the status of your program. If you specify
0, isis_accept_events() always returns instantly, even when there was
no event to accept.
6. In old ISIS programs that called, e.g., cbcast(..., 0) (asynchronous)
the broadcast call never blocked. This was causing real problems for
us, and ISIS now might block during such a call. That is, other
messages could be received between when you call cbcast asynchronously
and when the call returns. You can avoid this using the "f" option in
bcast_l, but the cost of "forking" many broadcasts off at one time
could be high, so be careful about this.
Again, we encourage everyone who has been using ISIS to switch to ISIS V1.2
at this time. And, if you run into any problems at all, please let us
know and we'' fix things for you.
Ken Birman