[cap-talk] Tamed Pict

Matej Kosik kosik at fiit.stuba.sk
Wed Mar 4 13:10:49 EST 2009

Toby Murray wrote:
> On Wed, 2009-03-04 at 13:48 +0100, Matej Kosik wrote:
>> Very short description of relationship among Pict, Tamed Pict, Sahara
>> can be found here:
>> http://altair.sk/uploads/tmp/introduction.pdf
>> Relevant text starts at page 4. The paragraph above the figure.
>> Pict is finished.
>> Tamed Pict is finished.
>> Sahara is finished.
> That's awesome. I can't wait to read the rest of your thesis. 
> In the meantime, could you clarify a few things for me about Tamed Pict.
> Processes in Tamed Pict run concurrently. Hence it is multi-threaded.

The original Pict has a construct for inlining arbitrary C code, so what
can you do in C (spawning native threads or separate processes) can be
done also in Pict. That ability to inline arbitrary C code is very
useful, although using of `fork' syscall is not necessary because Pict
supports also "green threads" or "green processes"
For many purposes this is sufficient concurrency mechanism.
(the term "green process" was probably introduced by Erlang folk to
stress certain difference of their language over other languages that
support green threads).

> Sending of messages between processes in Tamed Pict is nominally
> asynchronous because it is so in Pict
> -- quoting from Pierce and
> Turner's "Pict: A Programming Language Based on the pi-Calculus":
> "We allow only asynchronous output in Pict; this amounts to restricting
> the 'continuation' of each output expression to the null process."
> (I say nominally because the reduction semantics would still be
> synchronous, but the programmer is forced to make all outputs happen in
> parallel with, and therefore asynchronously to, whatever else the object
> might be doing, due to the restriction that only the null behaviour can
> follow an output.)

yes, that's true.

> Tamed Pict has no nominally synchronous communication primitives because
> Pict doesn't. 

yes, that's true.

There are also other things which are not supported by Pict (partially
because they are superfluous) and they are available in the original

Those omissions mostly simplified the implementation significantly
affecting the expressibility.

> Does Tamed Pict allow you to test equality between two channels/names ?

No. This is one of the things that was omitted (despite that it could be
trivially implemented).

> I need to think harder to work out whether Pict's derived forms for
> recursive functions allow you to write recursively reentrant code (see
> http://mail.eros-os.org/pipermail/e-lang/2009-February/013002.html for
> more on what I mean here).

I cannot give you sure answer because I do not exactly understand what
problem you discussed there. In this paragraph:

"The thing that both of these attacks had in common was that they
exploited reentrancy-via-recursion. In both cases, an object, o,
implementing some abstraction must maintain some invariant. o must also
call some untrusted code. While calling the untrusted code, o can be
invoked recursively. This reentrant invocation of o causes its internal
invariants to be broken."

What do you mean by "While calling the untrusted code, o can be
invoked recursively." ? What do you mean by "recursively"? Who could
invoke object o "recursively"?

(the answer might probably lie in the examples provided by David Wagner
written in Caja, but I haven't learned Caja so far).

More information about the cap-talk mailing list