Subject: Re: group descriptors

From: Tony Skjellum <[email-masked]>
Date: Wed, 10 Mar 93 00:05:40 CST

This corrects the second message, accidently sent only to Rik.
- Tony

---



Rik, I was foolish not to mention that we have implemented a registration
mechanism with trees, in Zipcode 1.0.  The user can add available
methods for combine, and then,when a mailer is created, specific 
choices can be taken from the list.

Currently, we implement with numbers, but this could be done with names,
to allow better sharing.  I will check on choices we made.  It has been
some time since I worked on that internal code.  

Anyway, I concur on the need to have registerable choices, that allow
sharing, per your letter.  As regards new functionality, they could go
in the tree too, but there is no structural mechanism in Zipcode,
other than defining a class' method list, for adding new instantiations
to a mailer at creation.  All of this was very elaborate coding, which
I will elucidate in my article for Rolf.  I am happy to share details
with you as well, beforehand.

- Tony

---

From: [email-masked]
Date: Wed, 10 Mar 93 11:08:53 PST

Tony writes

> with you as well, beforehand.

Maybe I haven't thought about this enough, but I do not understand
why elaborate coding is required if we do everything at runtime
and do not try to provide type-safety.

No one has yet pointed out a deficiency with my proposed interface:

      MPI_set_group_attribute (gid,key,value,destructor_routine)
  and MPI_test_group_attribute (gid,key,&value)

This can be implemented at a data cost of adding a single slot to
a group descriptor (pointing to the attribute dictionary), plus a
loop in the group closing routine to call the destructors (if any),
plus the routines to manage the dictionary.

I do not believe that there would be much resistance from the
committee to adding this capability, since it seems to be easy
to implement and (almost) "free if you don't use it".

What have I missed?

--Rik Littlefield

PS. OK, since nobody else has pointed out a deficiency, I will.

    The definition provided above does not support transferring
    attributes between processes.  

    The uses that I had in mind involve information that is so
    local to the process that transferring it doesn't even make
    sense (e.g., lists of partners for collective comms).

    If one wanted to define attributes that could be transferred,
    the interface would have to be extended.