ken@gvax.cs.cornell.edu (Ken Birman) (06/09/89)
Summary of changes to ISIS:
Some very visible changes:
o address structure no longer passed by value/returned by value
Affects almost all ISIS system calls.
o The output formats that required structure passing by value
are no longer permitted: %a,%e,%p and %b. Use %A...%B instead.
A new format, %X[const] has been added, for fixed-size arrays,
and %-x, %+x is now supported for all data types.
o All broadcasts are now potentially blocking, even if no replies are requested.
o SUN OS users will need to link to library "lwp" now (although there is
a way to run SUN code without LWP, by defining NOSUNLWP in the master
ISIS makefile).
One annoyance.
o isis.h now needs to know the architecture of your
system (-DSUN3/SUN4/VAX/MIPS/APOLLO/HPUX/GOULD). If you don't
tell us, we make our best guess.
Many new features and other changes:
o Fortran->isis now works, but only tested from F77 on SUN3/OS4.0
o Allegro->isis now supported
o Ported to Apollo UNIX (10.1), MACH (tested only on NEXT machine),
MIPS (tested under under the DEC software release)
o Uses available lightweight process mechanism if possible:
SUN LWP, MACH Cthreads, Apollo tasks. Stack limit can
hence be eliminated, and arbitrary mixtures of native and
ISIS tasking are permitted. Pre-emptive tasks are supported
(but only one task can be actively using ISIS mechanisms at a time)
This change affects calls to fork(), vfork(). See the manual for details.
A big advantage that came with making this change is that most
of the ISIS routines can now be called directly, without worrying about
tasks, and the stack size limit on the "main task" is eliminated.
o isis_mainloop() no longer mandatory; can use isis_acceptevents instead
o isis_accept_events: now requires a flag
o BYPASS communication facility gives huge speedup, supports
specialized user-provided transport protocols
o isis_entry_stacksize(enum, size): sets stack size for specific entry
o Suntools users should call isis_suntools_init(port-no) instead
of isis_init(port-no)
o isis_input_sig: does a t_sig when input is available
o isis_signal_sig: does a t_sig when signal is received
o isis_chwait, isis_chwait_sig: does callback/signal when a child terminates
A few things to be aware of:
o SUN OS users will need to link to library "lwp" now.
o "exit()" may not do what you expect!
Details:
o address structure no longer passed by value/returned by value
This affects almost all ISIS system calls, but because the
change is so pervasive, most programs can be fixed by changing
declarations from `address' to `address*'. For example,
say you used to write:
...
address gaddr, my_server;
gaddr = pg_lookup("group");
bcast(gaddr, HELLO, "%a", my_address, 1, "%a", &my_server);
In ISIS V1.2 you would code this as:
address *gaddr_p, my_server;
gaddr_p = pg_lookup("group");
bcast(gaddr_p, HELLO, "%A[1]", &my_address, 1, "%a", &my_server);
If the server used to do this:
if(addr_ismine(mgv->gv_members[0]))
reply(mp, "%a", my_address);
Now it would be changed to this:
if(addr_ismine(&mgv->gv_members[0]))
reply(mp, "%A[1]", &my_address);
[ Comment: we did this because passing of structures by value ]
[ was just not portable. Too many problems were caused by this ]
[ feature, and we lost too much time supporting it... ]
One issue to be aware of is that address pointers may not
be "stable" in all cases:
o pointers returned by msg_getsender, msg_getreplyto, etc. point
into the message and become undefined if the message is deleted.
The same comment applies when you use "%-a" in msg_get.
o pointers returned by pg_join, pg_subgroup point to a
structure that remains valid as long as you remain in the group.
pg_leave will invalidate these pointers
o pointers returned by pg_lookup on groups to which you don't
belong are copied into a safe place and saved indefinitely.
If you have a space problem call addr_free(addr_p) and ISIS
will get rid of this small space using a ref counter scheme.
We added casts so that calls to addr_cmp, addr_ismine, etc.,
and to bis(), bit(), bic(), bclr(), bisv() will probably not
compile if the argument is passed by value instead of by ref.
o The output formats that required structure passing by value
are no longer permitted: %a,%e,%p and %b. Use %A...%B instead.
However, %a.. can still be used on input (in msg_get), because
this does not require by-value argument passing for us to support.
A new format, %X[const] has been added, for fixed-size arrays,
and %-x, %+x is now supported for all data types. We use %A[1]
and %-a in places where we used to use %a on output.
There are some examples of this above. Notice that if
you used to say
msg_put(mp, "%a", addr);
you can change this fairly easily to
msg_put(mp, "A[1]", addr_p);
On the receive side, this works too: if you used to say
msg_get(mp, "%a", &addr)
now you can use either of the following:
msg_get(mp, "%a", &addr) -- as before
msg_get(mp, "%A[1]", &addr) -- uses new %A[1] format
the latter has the advantage of matching the format in the msg_put
o Fortran->isis now works, but only tested from F77 on SUN3/OS4.0
The basic interface is the same, but you include "fisis.h"
(name your source file myfile.F to get the C preprocessor to
run) and omit the underscore character everywhere. However,
some care must be taken with address variables. See the
new manual section on this subject.
o Allegro->isis now supported
As for fortran, the basic interface is the same, but you'll
need to read the manual section to take advantage of this port.
o Ported to Apollo UNIX (10.1), MACH, DEC 3100
We've only run the MACH port on NEXT machines, but it seems
quite solid on this hardware. It uses Cthreads and should
port to other MACH versions without changes.
The MIPS (3100) port is recent but seems very solid and fast.
o Uses available lightweight process mechanism if possible:
SUN LWP, MACH Cthreads, Apollo tasks, Allegro processes. Stack limits
depend on the native mechanism, and arbitrary mixtures of native and
ISIS tasking are permitted. Pre-emptive tasks are supported
(but only one task can be actively using ISIS mechanisms at a time)
That is, tasks can be run pre-emptively now, but a task
that wants to enter ISIS or that ISIS starts (including
callback tasks) will hold a mutual exclusion lock called
isis_mutex. Thus, ISIS itself continues to do things
non-preemtively, but you can exploit true preemption in the
rest of an application (say, for cursor tracking) provided
the high priority tasks don't call into ISIS.
You can mix native and ISIS task calls arbitrarily now.
ISIS emulates its own t_fork, etc, using native calls when
possible.
SUNOS users will need to link to the library "-llwp". Also,
note that ISIS uses a define to alias "exit" to "_exit"
under SUNOS, because the semantics of "exit" were changed by
SUN in a bizarre way that might surprise you otherwise.
You can avoid this using a define -DNOSUNLWP, see the SUN3/README
file for details.
[ Comment: these changes eliminate the assembler code from ISIS! ]
o isis_mainloop() no longer mandatory; can use isis_accept_events instead
o isis_accept_events(flag): The flag is new (and required). 0 operates
asynchronously, ISIS_BLOCK means "don't return until something has
been done."
The way that ISIS runs the task subsystem has been substantially
changed (enhanced, actually). The core routine is now the one
called isis_accept_events, which is told either to block or to
run asynchronously. In the former case, the call will return when
at least one task has done something. This may block. In the latter
case, the call will return immediately if there was no work to do.
The changes are useful when running existing programs under ISIS or
when working within an existing lightweight task package. They
permit arbitrary tasks to enter and exit ISIS at will and allow
you to avoid the isis_mainloop routine -- which was a bit of
a problem previously, when integrating existing code into ISIS.
Stack size limits used to be a concern and might have forced
you to call t_on_sys_stack, which works but was a bit painful.
In the new scheme, the old program runs as it always did, but
periodically invokes isis_accept_events(0/ISIS_BLOCK) to let
ISIS run for a while. The old isis_mainloop() can be thought
of as running isis_accept_events(ISIS_BLOCK) in an infinite loop.
* The nice outcome of all this is that you can now write a fairly
* normal C program under ISIS, without forking off the main task.
* It would call isis_init, etc. directly from main, and then could
* join groups (again, directly from main), call isis_start_done, and
* then do its thing, periodically calling isis_accept_events (at least
* when data is available on isis_socket or intercl_socket.)
o BYPASS communication facility gives huge speedup, supports
specialized user-provided transport protocols
This is an experimental feature (e.g. it probably is still buggy
in V1.2) and we don't compile it in by default yet. If you enable
it, cbcast (and fbcast), but not abcast, are transmitted directly
in the following cases: member to whole group (including "x" option),
member to clients (a new "c" option), and reply from a member to
a member or to a client. You can sometimes get the effect of a
fast abcast using a "cbcast token", but be aware that this might
not be ordered w.r.t. abcast sent via the normal abcast protocol.
We will be allowing users to define their own protocols for
multicast message transport, too. See the manual (appendix D)
for details.
o isis_enter_stacksize(enum, size): sets size of task stack on
a per-entry basis.
o Suntools users should call isis_suntools_init(port-no) instead
of isis_init(port-no) (SUN OS 4.0 and subsequent revisions)
o isis_input_sig: does a t_sig when input is available
o isis_signal_sig: does a t_sig when signal is received
o isis_chwait, isis_chwait_sig: does callback/signal when a child terminates
This lets you know when it is safe to call `wait'.
o "exit()" may not do what you expect!
Specifically, on SUN LWP the semantics of "exit" were changed (wrongly!)
by the LWP people to mean "terminate the current task". This is rarely
what the user intended, since it leaves the process running. So, ISIS
defines "exit" to be "_exit" under SUNOS. This, however, may fail to flush
output channels. You can undefine our define if you like.
There seems to be a related problem on APOLLO UNIX 10.1, but since
the APOLLO documentation says nothing about it, we think it is an
APOLLO bug.