[gridrpc-wg] Fwd (pbellens at ac.upc.edu): Re: [Fwd: [saga-rg] Re: saga update... (iii)]
Andre Merzky
andre at merzky.net
Wed Mar 22 16:08:06 CST 2006
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
More information about the gridrpc-wg
mailing list