I apologize for using the wrong term. I agree it is knowing progress
has happened and completion can be marked. You and Koichi seem to be
going after the same general idea. I think it is a reasonable one. I
will try and write up some text for the release tomorrow. It will be
an option to vote on.
> > > 3) May be it is close enough to the final draft that I can talk a little
> > > about binding issues. There are these 6 calls in the draft
> > >
> > > MPI_Set_request_tag(request, tag)
> > > MPI_Set_request_source(request, soruce)
> > > MPI_Set_request_error(request, error)
> > > MPI_Set_request_count(request, count, datatype)
> > >
> > > MPI_Set_status_count(status, count, datatype)
> > >
> > > MPI_Request_mark_complete(request)
> > >
> > > It is probably preferable to have just this 3 function
> > >
> > > MPI_Set_status_error(status, error)
> > > MPI_Set_status_count(status, count, datatype)
> > >
> > > MPI_Request_mark_complete(request, status)
> >
> > The fundamental difference seems to be between associating the info
> > with the request or the status. With the proposed system you save 4
> > functions (you don't need MPI_Set_status_error since error is not
> > opaque). The tradeoff is that you need to have a status at the
> > MPI_Request_mark_complete. When you do a Test/Wait, what is put in
> > the supplied status? I assume it is the same info that was provided
> > in the status at the MPI_Request_mark_complete. I think the current
> > design is cleaner since you only have 1 status. You need to pass or
> > create a status object where ever MPI_Request_mark_complete is called
> > in the new design. I am happy to hear counter arguments.
>
> When you do a test/wait, if the request is completed, the status
> supplied by MPI_Request_mark_complete is request. There is only one status.
I'm afraid I am missing something here. I'm not sure what the last
paragraph means. Sorry for being slow. If we can't resolve it now we
can do it at the meeting since it seems to be binding.
>
> The only reason for discussing binding is for convenience. The
> routine that uses these facilities probably has an internal date structure
> that holds these information and sets them up, so it might as will keep
> it the data structure called MPI_Status, and pass it in 1 call instead
> of doing 4 calls.
>
> As I have said, the functionality is equivalent, and it is just
> a binding issue.
>
> >
> > >
> > > 4) I also argue that you will need MPI_Status_create and MPI_Status_free
> > > for layerability.
> >
> > I don't think you need such functions. You can create a status object
> > by mallocing the MPI_Status structure or with static declaration if
> > you are in Fortran and cannot malloc. You do something like:
> >
> > status = (MPI_Status)malloc((size_t)(sizeof(MPI_Status))
>
> I thought that MPI_Status is a semi-opaque object, if you allow me
> to do a malloc and use it, than it is not an opaque object, for example the
> implementation cannot put magic number in it. I don't mind if status is
> not an opaque object, it just have to be defined that way.
I see it now. status is semi-opaque. I think what we need is a
status initialize (and de-intialize?). You can create the necessary
memory but when you pass the status to an MPI routine it may modify
obaque parts of the object for later use. A non-MPI use could not do
this. However, I suspect that this is not the case in
implementations. The opaque part was meant to be the count field. We
should inquire if we need to worry about other opaque fields.
Steve