RE: IM33: Modifying and/or sending messages received

Hi Russ,

> I believe the spec adequately describes the limited scope and
> lifetime of SceMiMessageData objects received through an
> OutputPortProxy.

Agreed, but the issue was not this, but whether the spec allows or
should allow these objects to be sent to input ports. Although
this is a minor issue and probably uncommon usage, what the spec
says does affect the implementation. For instance, if the spec
explicitly forbids this usage, then the implementation could take
advantage of this in how it internally handles and implements
SceMiMessageData objects. Note, the SceMiMessageData class is only
the interface the application sees and more state may be kept under
the hood that differs depending on the direction of message
transport.
 
> I would suggest, without any real fervor, that whether a user
> chooses to construct once and store SceMiMessageData objects for
> use with an InputPortProxy or "use once and discard" is an
> implementation detail best left to the users and requires no
> further clarification.

The point of adding the clarification was to ensure that all SCE-MI
implementations support both of these use models. This is
important for portability. If we do not specify whether reusing
SceMiMessageData objects are allowed or not, then there is a risk
that eventually some implementations will allow it while others
will not.

> Since we're dealing with a C++ class here, and we're passing it
> to Send() via a const reference, the proposed clarification
> amounts to a C++ truism.

It is not that simple because the SceMiMessageData class is just
the interface. There is no requirement in the spec that the
SceMiMessageData class contain all the information related to
a message. It is quite possible to envision a case where
forbidding reuse of SceMiMessageData objects could lead to a
more optimized implementation. In fact, allowing reuse makes it
harder for the implementation to avoid a data copy.

> The requirement that SceMiMessageData objects have the same
> width as the ports they're sent to is addressed in the description
> of the constructor in 5.4.5.1

True. Removing this, the proposal is now:

  Send()
 
  In Section 5.4.6.1, document p. 53, PDF p. 61, after the
  sentence under
  `data' add:

    This object may be arbitrarily modified after Send() and used for
    an arbitrary number of sends to the same and other message ports.
 
  Receive()
  
  In Section 5.4.7.1, document p. 55, PDF p. 63, after the last
  paragraph in the section add:
 
    The class SceMiMessageData object passed to the receive callback
    may be sent any number of times to any number of input ports.
    Modifying the class SceMiMessageData object by casting away const
    leads to undefined behavior.

> Changing subjects, after reading the spec some more, I found
> what might be a
> separate issue. The CycleStamp() accessor for
> SceMiMessageData objects is
> presented in the spec (p52, PDF 60) without any description
> of what would
> happen if a renegade user were to call it on a
> SceMiMessageData object not
> originating from an OutputPortProxy. Should the accessor call
> the port's
> error handler in this case, return 0, or is "undefined
> behavior" adequate?

I don't think undefined behavior is good. I think it makes sense to
make this an error, but unfortunately, CycleStamp() does not have a
SceMiEC argument so we cannot make it an error without changing
CycleStamp()'s declaration. If doing this is not an option, the only
reasonable choices left are to return 0, or, perhaps better, return
the most recent value of cycle stamp received through an output proxy.

Regards,
Per

-- 
Per Bojsen                                Email: <bojsen@zaiqtech.com>
Zaiq Technologies, Inc.                   WWW:   http://www.zaiqtech.com
78 Dragon Ct.                             Tel:   781 721 8229
Woburn, MA 01801                          Fax:   781 932 7488