[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (now completed) Slides from my talk at CPA2000
----- Original Message -----
From: "Tom Locke" <tsl2@xxxxxxxxx>
To: <occam-com@xxxxxxxxx>; <java-threads@xxxxxxxxx>
Sent: Tuesday, 05 December, 2000 9:42 AM
Subject: RE: (now completed) Slides from my talk at CPA2000
>
> At 11:34 01/12/00 -0700, Campbell, John wrote:
> >Having looked at your slides, I like the thinking. I do, however,
> >have some misgivings. Perhaps one of the theoretical types can
> >comment on this, maybe set me straight. But it seems to me that
> >CSP lacks the power to describe an object passing through a pipe.
>
> There's a lot that CSP can't describe isn't there? occam does a lot that
> you can't do in CSP.
>
> Sending processes down channels:
> In occam, there is no way to get a handle on a process, only its channels,
> so there would be no way to go about sending a process down a channel. I'm
> thinking on the same lines - there will be no 'process names' in this
language.
>
> Here's how it works. There's an operator along the lines of OO's 'new'
> which launches a process and returns a channel record containing this
> processes interface. When we talk about sending a process down a channel,
> we are actually sending the channel record. Analogously, in OO we always
> talk about passing objects around, whereas we actually pass references to
> objects around.
Why not really send a process? For a distributed machine I might have a
piece of code I want to be executed elsewhere - in HAVi, for example, the
controller resident part of device driver is a Java byte code that is sent
to any controller that asks for it. In practise this is often the most
"metastable sensitive" period of the network's operation as many devices are
doing the same thing whilst controllers are initialising and so any
formalism that captures design issues there is valuable.
And not to mention completely dynamic systems.........
> The send has a 'move' semantics - the sender no longer has the record.
Only
> one (serial) client ever holds the channel record.
>
> >The problem is that it's not much of an object if you have to sever
> >its existing channel connections before sending it.
>
> Could you elaborate on this?
>
> Thanks,
>
> Tom.
>
>
>
>