pyro & parallel processing

[Robin Becker]

In article <am53og$hdl$1 at news1.xs4all.nl>, Irmen de Jong <irmen at NOSPAMRE
MOVETHISxs4all.nl> writes
>Syver Enstad wrote:
>> Robin Becker <robin at jessikat.fsnet.co.uk> writes:
>> 
>>>Has anyone used pyro to do symmetric parallel processing. The pyro
>>>framework is nice with master slave type applications, but the remote
>>>objects don't seem to be able to message back to their invoker.
>> 
>> They can, checkout the callback examples in the Pyro distro. Basically
>> what happens is that you pass a Pyro proxy as a parameter to the a
>> method on the Pyro object. 
>
>This is a good way of letting the 'other' Pyro object call methods on one
>of your 'own' (or 'local') objects. It is a more symmetric way but
>you have to pass callback object proxies as parameters.
>
>The other - fully symmetric - way, is to build some Pyro objects
>on both sides and register them all with the Name Server.
>This way everybody can discover the other's objects by themselves.
>You won't need to pass callback object proxies around.
>Note that this requires a Pyro server (daemon) on all nodes,
>but that is no different from the callback object solution.
>
>Irmen de Jong
>
>PS  the Pyro mailing list is usually a better place to ask questions
>about Pyro, see http://lists.sourceforge.net/lists/listinfo/pyro-core
>
well actually I think I need a mostly master-slave relation, but would
like the slaves to be able to pass information back to their masters for
redistribution to the other slaves. The kind of thing I'm thinking of is
parallel alpha-beta search with cutoffs. I think this is best done by
having a single master which has all the workers as its slaves. When the
worker finds a new global best it can pass this to the master using a
reasonably simple call back mechanism.

The master can presumably pass the new global cutoff to the slaves, but
I'm not sure yet how interruptible I can make them, so I guess my second
question is can we have asynchronous calls into the workers or do I need
to have multiple published classes with a common thread protected state?
-- 
Robin Becker