[cap-talk] A Taxonomy of Current Object-Cap Systems

Mark Seaborn mrs at mythic-beasts.com
Wed Mar 4 19:06:19 EST 2009


Toby Murray <toby.murray at comlab.ox.ac.uk> wrote:

> The current features of the taxonomy are the following:
> 
> OS / Language - whether the system is an operating system or programming
> language. e.g. EROS is an OS. E is a language.

Perhaps there should be a third category: protocols.  Plash's
object-capability protocol would fit into that category
(http://plash.beasts.org/wiki/PlashObjectCapabilityProtocol).  It is
OS-based but it is not an OS.

Are you only considering pure capability systems?  Unix file
descriptors, and in particular Unix domain sockets could go on the
list.  The comparison would be useful, considering that sockets are
connection-based (unlike EROS/CapROS/Coyotos and typical
language-based objects) and often not message-based.

> Single-Threaded - whether objects in the system all share a single
> thread of control e.g. E and EROS do not. Joe-E does.

Plash: multiple threads (processes in this case).

> Inter-Thread Sync. Sends - whether the system allows objects running in
> different threads of control to send messages to each other
> synchronously, e.g. E does not, EROS does. This is not applicable for
> Single-Threaded systems.

Plash: yes.  Synchronous call-return is layered on top of a core async
protocol.

> Recursive Reentrancy - whether the system automatically allows objects
> to be recursively invoked, e.g. E does. EROS does not.

Plash: yes.

> Async. Comms. - whether the system allows asynchronous communication
> between objects. If so, whether it allows async. sends, receives or
> both. e.g. E allows both async. sends (<-) and receives (when (p) ->
> {...}), Joe-E allows niether.

Plash: yes.

What do you mean by async send without async receive or vice-versa?

Promptness of transfer, and whether messages need to be queued, is
possibly another feature in the taxonomy.

> EQ - whether the system provides an EQ implementation (even if it is not
> universally available to all objects), e.g. EROS/CapROS do (via
> Discrim), as do most languages (via '==').

Plash: yes, but preserving identity is optional.  When sending an
object reference multiple times, a protocol implementation can (but
does not have to) reuse the same object ID.  Similarly, when receiving
the same object ID multiple times, the implementation can choose to
reuse proxy objects.

Currently the Python implementation preserves identity but the C
implementation does not.

Cheers,
Mark


More information about the cap-talk mailing list