Re: ext. chapter

Steve Huss-Lederman (lederman@cs.wisc.edu)
Mon, 28 Oct 1996 08:05:54 -0600

Rajeev has raised some points about the draft of 25 October 1996.
Here are my thoughts:

> 1. What's missing in the generalized requests section is a way to
> start a nonblocking nonpersistent gen. req. This is outlined on
> 127/9-17, but not defined anywhere. We need a defn. for
> MPI_IDO(meta_req, extra_state, request)

The text here is wrong. The correct text is on 129/17-20. The
MPI_IDO function no longer exists. You now use MPI_START. This will
be fixed.

> Note that extra_state is needed here, not in MPI_Meta_request_crate
>
> To implement an MPI_Iwrite, I will do an MPI_Meta_request_create once
> when the I/O library is initialized.
> Later on, whenever MPI_Iwrite is called, I will call MPI_Ido and pass
> the paramters of MPI_Iwrite to MPI_Ido in extra_state. This
> extra_state must be passed to the start_fn, not the one in
> MPI_Meta_request_create.
>
> Therefore, I suggest that extra_state be removed from
> MPI_Meta_request_create and moved to MPI_Ido for nonpersistent and
> MPI_Meta_request_init for persistent.

I have thought about this. At the meeting earlier in the month I
mentioned (to at least some people) that removing extra_state to the
creation had the above effect. The people I talked to felt it was
ok. What we agreed would be done is that the implementor could
still have the handle to extra_state from the create call, so the new
information can be added when you go to restart the request. The
positive consequence of this is that you can use MPI_START to begin a
request (correction above). The negative is the user must be a little
more careful. For example, if you can have the same request active at
the same time, you have to be careful to keep the parts of extra_state
straight. I am willing to add in a discussion item about this, but am
nervious about making a change at this point. I think it is
non-trivial because it effects a number of functions. Thoughts?

> 2. Regarding 142/34-37, you are right. You could delete the Advice to
> implementors (142/30-32, 143/6-8). Instead add regular text saying
> something like
>
> "The value of MPI_ERR_LASTCODE is not affected by new user-defined
> error codes and classes. Instead, MPI_ERR_USER_LASTCODE gives the
> maximum value for new user-defined error codes and classes.
> MPI_ERR_USER_LASTCODE >= MPI_ERR_LASTCODE"
>
> You can give it another name if you can think of a better one.
> Also, should MPI_ERR_USRE_LASTCODE be a constant, or should it
> increase with each call to MPI_Add_error_codes or MPI_Add_error_class?
> If we make it a constant, there will be a limit to the number of error
> codes that can be added in this fashion.

I think it is not a constant. It changes each time the user adds a
new error code. I will make this change and add an advice to users
about being careful in a multithreaded environment and not to assume
it is a constant.

> 3. The answer to 143/31 is "the same as what would happen in MPI-1 if
> a user passes an invalid error code to MPI_Error_class or MPI_Error_string."

Will note this in text.

I am editing the chapter to make these changes. I am also updating
the generalized request example. I welcome thoughts/idea but you need
to get them in soon (now) since tomorrow is the deadline.

Steve