[gridrpc-wg] Fwd (pbellens at ac.upc.edu): Re: [Fwd: [saga-rg] Re: saga update... (iii)]

[Andre Merzky]

Hi all, 

I got following forward from Rosa Badia, as an answer to the
saga-rpc proposal.  Pieter makes some interesting points...

Cheers, Andre.


----- Forwarded message from pbellens at ac.upc.edu -----

> Date: Mon, 20 Mar 2006 10:47:18 +0100
> From: pbellens at ac.upc.edu
> To: rosa.m.badia at bsc.es
> Subject: Re: [Fwd: [saga-rg] Re: saga update... (iii)]
> 
> #include <saga.hpp>
> 
> string func_name   = "pi/pi_trial";
> string config_file = "file:///client.conf";
> 
> int main (int argc, char *argv[])
> {
> ..
>     std::vector <long>   count;
>     saga::task_container tc;
> 
>     for ( int i = 0; i < n; i++ )
>     {
>       // create rpc handle
>       saga::rpc  handle (hosts[i], func_name, config_file);
> 
> --> In Ninf-G, one creates an object handle that specifies a host and a module
> name, where a module can contain anywhere from 1 to many functions. That comes
> in really handy, since you can access a lot of functions with a single object
> handle creation call. For the case above, you would need 100 handles to access
> 100 functions. Unless you start wrapping those functions, but that s a lot of
> work, and pretty ugly. The object handle/Ninf-G case is not part of the
> official GRPC standard though, whereas the SAGA handle initialization does
> follow the standard. Personally, i prefer Ninf-G's approach here.
> 
> 
> 
>       // perform async call
>       saga::task t = handle.call <saga::async> (i, times, &count[i]);
> 
> --> Because the handles are treated different, the GRP call itself differs as
> well. I don t see how they pass a callback function, though. In Ninf-G, each
> asynchronous GRP call contains a callback function as an argument. 
> 
> 
> 
>     // wait tasks (for ever, for all)
>     tc.wait (-1.0, saga::task::All);
> 
> --> Here you wait on a function container, in Ninf-G one waits for individual
> function calls. Although you can wait for several functions, by using logical
> AND or OR functionality. This is an interesting feature of SAGA, although we
> don t need it.
> 
> 
> .. 
>   return (0);
> }
> -----------------------------------------------------------
> I realised that I forgot the config_file argument to the
> handle creation in the last (synchroneous) example - it
> should look like above.  That actually _is_ a difference to
> GridRPC: as the session in SAGA is not RPC specific, it
> makes no sense to have a RPC specific config file for a
> session.  Hence, the config file would need to be attached
> to the handle creation.
> 
> --> This makes sense. However, it would make sense to gather all configuration
> files into one single file, and use that single file at runtime initialization
> time, just as Ninf-G does.
> 
> kind regards,
> 
> pieter

-- 
"So much time, so little to do..."  -- Garfield