[SAGA-RG] SAGA Message API Extension

Hartmut Kaiser hkaiser at cct.lsu.edu
Sat Jan 20 13:17:29 CST 2007


Hi Andre, 

> here is the updated draft of the SAGA Message API, in 
> preparation for OGF-19.  It is also available in CVS, as usual.
> 
> We would be happy to get feedback on the list of course, so 
> don't feel oblidged to hold back your comments for OGF-19
> :-)

Sorry, it took me some time to digg through the new spec... I had to start
implementing the stuff to have comments (I'm perhaps too old to do
programming other than in an intuitive way :-P).

The comments I have relate to the API part of the spec. 

Frankly, I don't like the design of the 'msg' object, I even think it's not
viable to make it a first class SAGA object (derived from saga::object) - is
there a use case requiring that?

The msg object in its current design mixes two different paradigms into one
object (remember: every kind of bool in an API is a strong hint for a flawed
design):
a) saga::msg can be a wrapper object for application memory (size > 0) and
b) saga::msg can be a object managing memory on behalf of the SAGA
implementation (size == -1)
I strongly believe that we don't need b) and even if we do, it should be
implemented in a separate abstraction. 

Why do I think we don't need b)? 

Instead of relying on the SAGA implementation to manage the memory for the
application (BTW: this is the only instance in the whole spec, where we
require the implementation to do this), an application always may write
(syntax is C++):

    endpoint ep(...);
    ep.connect(...);
    int size = 0;
    if (ep.test(..., &size)) {
        void *data = new unsigned char[size];
        ep.recv(data, size);

Or even better:

        ep.recv(buffer(data, size));
        ...
        delete data;
    }

i.e. The application always can handle the memory itself, without having to
go through too much overhead.

This brings me to the second comment: by implementing the msg/buffer object
solely for the purpose of wrapping up application memory this msg/buffer
could be reused for other packages as well: file::read, file::write,
stream::read, stream::write, rpc::parameter::buffer - to name a few. 

BTW: I silently introduced a const_buffer and mutable_buffer objects,
combined with a buffer() generator function in the C++ implementation of the
saga::file package to improve memory handling in the API.

Regards Hartmut







More information about the saga-rg mailing list