[saga-rg] Re: [gridrpc-wg] Final call: GridRPC API for inclusion in SAGA 1.0
Andre Merzky
andre at merzky.net
Thu Aug 10 04:04:22 CDT 2006
Hi,
Quoting [Thilo Kielmann] (Aug 10 2006):
>
> Andre,
>
> thanks for your comments. More or less, we agree on this.
> more comments inlined (why should YOU not be forced to search for them? ;-)
Fair enough :-P
> BTW: most deficiencies you rightly spotted are parts of the text that we
> simply inherited from your presious version. Feel free to fix ;-)
Well, that was the reason why rpc was not included in the
spec, yet. If I'd had the ability to fix the stuff myself
I might have done it already, but I'm afraid I don't...
> > I felt free to change some part to adapt it to the spec look
> > and feel (example coding conventions, intendation etc.).
> > I'll convert that version to tex now, and add it to the
> > CVS. Hope thats ok with you.
>
> Actually, I was hoping for this.
hehe, worked...
> > There is one conflict: I hope that we can get the SAGA CORE
> > spec into final mailing list call on Monday. So I suggest
> > to NOT move that timeline backwards, but to include rpc
> > already - if either of the final calls meets negative
> > comments we remove it - does that make sense?
>
> There is no conflict. Just, SAGA folks have a few days more to object...
*nod*
> > > gridrpc - scheme - identifying a grid rpc operation
> > > server.net - server - server host serving the rpc call
> > > 1234 - port - contact point for the server
> > > my_function - name - name of the remote method to invoke
> > >
> > > All elements but the scheme can be empty, which allows the
> > > implementation to fall back to some default remote method to
> > > invoke (minimal URL: gridrpc:///).
> >
> > The description of the constructor says that the URL can be
> > NULL, in some languages that will mean 'empty' (e.g. if they
> > have no default args). That would mean that scheme can be
> > empty, too.
>
> what does this mean? is this a problem?
No, not a problem, but a contradiction:
"All elements but the scheme can be empty ..."
"An empty URL means ..."
I would prefer to allow the URL to be totally empty.
> > Not that I disagree, but it should be noted that even for
> > RPC calls which require input parameters only, the params
> > must be passed by reference. That implies, in some
> > languages, to track the param memory for async invokations,
> > where that is not the case for async invokations of other
> > languages which don't have no output parameters. It can;t
> > be helped I guess, and should not be an issue really.
>
> fine, can you say this in SIDL, too? ;-)
It is implicitely expressed in SIDL already. We might want
to add a verbose note though
> > > This argument handling scheme allows efficient (zero-copy)
> > > passing of parameters. For 'Out' parameters with a size value
> > > of 0, the implementation is required to allocate the data
> > > structure and to overwrite the size and buffer fields for
> > > the parameter.
> >
> > It is the responsibility of the application programmer to
> > free this memory I assume? The the language bindings MUST
> > prescribe how that memory is allocated, to allow the
> > application to choose the appropriate de-allocation method.
> > Alternatively we would need an 'dealloc' method, which would
> > then require the implementation to alloc and de-alloc the
> > params (and to keep track of the blocks).
>
> yep, we can add a sentence pointing out that this needs to be addressed in the
> language bindings.
>
> > I assume a number of other exceptions would apply as well,
> > such as
> >
> > AuthenticationFailed
> > AuthorizationFailed
> > PermissionDenied
> > DoesNotExist (server contacted, but no such call available)
> > IncorrectURL
> >
> > Well, and some more I guess. Question is: NoSuccess is
> > actually reserved as last resort, if no other exception
> > really applies (its the least specific exception, please
> > have a look at the 'error handling' section in the spec).
> > So, is NoSuccess really needed here, and in what conditions?
>
> this deficiency is nicely inherited from your old text. Can you please
> embellish this? (nobody really insists on 'NoSuccess'
Hmm, someone needs to go through the RPC spec and check what
errors are defined there, and map them to SAGA exceptions.
Volonteers? ;-)
> > > Notes: - see [1] for details
> > > - by passing an array of variable size,
> > > different numbers of parameters can be
> > > handled. No special variable argument
> > > list handling is required.
> >
> > We discussed varargs at one of the last GGF, and came to the
> > conclusion that language bindings COULD allow varargs. That
> > does not make sense with the proposed scheme, in particular
> > in respect to the memory allocation policy described. So, I
> > guess we abstain from varargs in the language bindings then?
>
> by this definition, we can avoid varargs. so let's do that?
Ok, fine with me.
> > Other open questions we had from former RPC discussions,
> > and which should be addressed in this spec, are:
> >
> > - GridRPC takes a config file name on initialization.
> > That config file needs to be user specific IIUC, and
> > there was some discussion, but no conclusion about that.
> > So, what is the appraoch on that? Is that spec
> > implementable on top of GridRPC, and how? If that is an
> > issue still: our decision was to include the config file
> > URL as (optional) parameter to the CONSTRUCTOR. Does
> > that make sense?
>
> Hidemoto, Yusuke, and I agreed to leave the config file out of the API.
> We think this is better. (Hidemoto was even harsher with himself who once
> put the config file into the gridrpc spec ;-)
hehe - ok, that makes things much easier.
> > - The RPC spec is silent about 'when' the connection to
> > the remote server is made, on creation of the handle, or
> > on call(). We decided in other parts of the spec that,
> > for example, the constructor opens a file, or remote
> > connection. I propose to prescribe the same for RPC.
> > Does that make sense? Do we need to loosen the
> > semantics elsewhere in the spec? (IMHO not).
>
> I am afraid, doing so would impose restrictions on the underlying gridrpc
> implementations. some of them might not meet them, but would still be useful
> if SAGA could access them.
>
> What you really would have in mind is a test "can execute" of the procedure?
> I am not sure if the constructor could aalready give a comprehensive answer???
>
> Hidemot, Yusuke, any ideas ???
>
> > - Ninf-G allows to bind a handle to multiple calls. I
> > assume that this is hidden in the implementation for
> > now, and has no explicit reflection in the API? I think
> > that is what we decided on anyway...
>
> looks like
Ok.
> > - should we add a 'cancel(in float timeout)'? Explicit
> > resource dealloction was an issue in our discussion at
> > GGF, and we agreed on cancel - is that not needed
> > anymore?
>
> hmm, wouldn't the cancel() belong to the task ???
No, I don't mean for async operations. For example (C++):
{
{
saga::rpc rpc (url);
rpc.call ();
// BTW: ar void calls allowed? i.e. can the param list
// be empty as default?
}
// the rpc handle is destroyed here.
}
So, the handle is destroyed - the programmer can, however,
not be sure that remote resources are really freed - thats
up to the implementation. In provious discussion we came
hence up with:
{
{
saga::rpc rpc (url);
rpc.call ();
// BTW: ar void calls allowed? i.e. can the param list
// be empty as default?
rpc.destroy (-1);
// remote resources are now freed
rpc.call ();
// this call woudl throw an IncorrectState exception
}
// the rpc handle is destroyed here.
}
That cancel() allows to explicitely free remote resources,
and can, if necessary, block until that is ensured. To have
that ability was actually a request by the RPC folx IIRC,
and we added it to several places in the SAGA spec (streams,
name space entries). So I guess we should stick to it here?
Cheers, Andre.
> Thilo
--
"So much time, so little to do..." -- Garfield
More information about the saga-rg
mailing list