From: ken@cs.cornell.edu (Ken Birman)
Subject: Re: About floats and being killed because not answering to requests
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Date: Fri, 9 Oct 1992 13:23:55 GMT

In article <1992Oct9.130958.28537@cs.cornell.edu>  simatic@aar.alcatel-alsthom.fr ( Michel Simatic ) writes:
>
>Could you tell a bit more about floats ?
>Do you intend to change anything in the way Isis handles them ?
>Could you give more details on parameter marshalling in Isis ?

Well, for floats, the problem is that even within one class of compilers,
say GCC, the rule for passing floats depends a lot on the architecture of
the machine and the rev level of the compiler.  Basically, "varargs"
just doesn't always work, in our experience -- sometimes they pass pointers,
sometimes values, sometimes the argument goes in a register.  I have no
idea why varargs isn't considered something you should test properly, but
we have been badly burned on this many times.

I guess I don't understand why you can't get the effect of
        bcast(..., "%f,%f", float1, float2)
by just doing
        bcast(..., "%F[1],%F[1]", &float1, &float2)

Your approach with %d won't be portable and won't byte swap correctly
on some systems.

As for the question about marshalling, what Isis does is to scan your list
of arguments and use varargs to pull the arguments in one by one (so: if
varargs doesn't work, we are up the creek.  It seems safe to use varargs
if you stick to integers and pointers... so we do).

Each argument is used to fill out a small structure which gives the type
and length of the field, followed by its data.  Byte alignment causes
the minimum size of a field to be something like 16 bytes (some machines
croak if everything isn't double-word aligned, basically).  This argues
for making fields big, or using the pg_buffer feature introduced recently.

If you have a spiffy marshalling mechanism of your own, or happen to love
XDR or something, you can just marshall into a memory region (xdr_mem,
for you XDR fans) and tell Isis the object is a big byte array.  Isis won't
mess with it.

We have no plans, right this minute, to change the scheme.  Long term,
we want to move away from varargs and do something more like stdio in C++.

>Problem 2 : Isis makes debugging more spicy
>
>when my programs stop at 
>breakpoints, I've got to be really fast in order to avoid the following message
>on station 1 :
>
>WARNING: many retransmissions to (21/0:3637.0)... continuing to retry
>WARNING: unable to communicate with (21/0:3637.0)... asking <isis/protos> to bre
>ak connection
>
>Of course, when I enter "cont" on station 2, prog2 dies and I swear because
>it takes 5 (very) long minutes to bring it back to life (my nickname is
>"Jesus" :-))
>I guess prog1 wants to send messages to prog2 and that, as prog2 does
>not answer, prog1 believes it is impolite (or worse dead) so that it does
>not want to talk to prog2 anymore.
>
As for debugging, we are thinking about how to fix this problem in V3.1
of Isis -- V3.0.7 will have the same "feature".  The problem is that
when you stop a program, you potentially stop the whole distributed
system, since Isis has no way to get replies on many of its protocols.
They start pinging the stuck process and eventually kill it off -- after
all, better to kill one balky process than to hang the whole steel mill.
You can always use isis_failed() to catch the disconnect and reconnect,
although this is not very clean.

In the next generation of Isis systems (HORUS, and the corresponting ISIS
system, which will be ISIS V4.0) we will eliminate this whole problem,
but that won't be available for at least 18 months.  Meanwhile, keep swearing!

The core problem is that when we put Isis on trading floors and places
like that, and by now we are on dozens of such "critical" applications,
the implications of letting the whole system hang are just much worse
than the limitation that individuals can't casually attach to their
applications with dbx, for long periods at any rate.  You do have about
45 seconds at a time.

With Isis, you are building a "community" of applications and in any
community, cooperation is a big factor in what can be accomplished.
For you, letting everything hang while you get coffee and think about
the state of the process may be the desirable behavior, but for some
big investment bank, this might leave the traders swearing (and when
that happens, you might as well forget about returning to your office
with that cup of coffee: your office will be occupied by someone else).

It would be nice to have a way to tell Isis that some chunk of programs
constitute a subsystem and that you want to use dbx on it.  If we can
think of a clean approach that would work, we'll add it in V3.1

Robert Cooper is the person thinking most about this (rcbc@cs.cornell.edu).
Email to him if you have clever ideas...
-- 
Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
Cornell University Ithaca, NY 14853 (USA)      FAX:     607 255-4428
Newsgroups: comp.sys.isis