Release of TCA Version 7.4

A new version of TCA has been released to /afs/cs/project/TCA/release/alpha.
Besides several minor bug fixes, this version has three major additions /
changes over previous versions.

1. In previous versions, tcaFreeData and tcaFreeReply could not handle
situations where the data passed was a null pointer, or if the associated
message format was null.  This has been changed.  The following syntax is now
always valid, and is the recommended way to define message handlers:

void fooHandler (TCA_REF_PTR ref, void *data)
{
  FOO_PTR fooData;

  fooData = (FOO_PTR)data;
  ...
  tcaSuccess/tcaFailure/tcaReply
  tcaFreeData(tcaReferenceName(ref), data);
}

2. In previous versions, message wiretaps that were goals or commands were
placed directly under the root of the task tree, regardless of which message
they were tapping.  This could cause problems: for instance, if the message
being tapped was killed, the wiretaps would be unaffected (since they were not
in the subtree of the message being killed).

Now, the "-t" command line option causes goal and command message taps to be
added as children of the message that was tapped.  Thus, when the subtree
under a tapped message is killed, so will all the associated wiretap mesages.
However, the wiretap is in general not visible when using the TCA utilities to
trace a task tree: for example, tcaFindLastChild, tcaFindNextChild, etc., will
never return a wiretap message.  The only exceptions are that
tcaFindChildByName will return a wiretap message of the appropriate name, and
given a wiretap message reference, tcaFindParentReference will return the
message that was tapped (the same information can be gotten by using
tcaFindTappedReference, which is more general since it works even if the
wiretap message is not part of the task tree -- e.g., it is an "inform"
message)

To allow time for users to make any modifications to their systems
necessitated by this change, the default behavior is still to place tap
messages under the root node of the task tree.  In subsequent versions,
however, the default behavior will change to placing wiretaps under the tapped
message, and the "-t" option will be reserved for specifying the current
behavior.

3. In previous versions, named formatters were expanded immediately upon
registration.  This could cause problems if a named formatter in turn used a
formatter defined by another module.  The solution was either to start modules
in a given order, or to register all component formatters of a named formatter
in each module.  This has been changed in version 7.4.  Now, named formatters
are expanded only when they are needed (i.e, the first time a message is sent
that uses the formatter).  As long as systems register all their named
formatters before calling tcaWaitUntilReady, this change will enable
developers to register named formatters only once, and the formatters will be
correctly propogated to other modules.

As always, send any comments or bug reports to me (reids@cs.cmu.edu) or Chris
Fedor (fedor@cs.cmu.edu).

Reid Simmons