[Isolate-interest] JSR-121 aggregates and links (strawman 10)

[Miles Sabin]

Godmar Back wrote,
> I'm not sure if it's a good model, but a model that provides an
> obvious parallel is Unix's way of passing file descriptors between
> processes using such mechanisms as cmsg(3)+SCM_RIGHTS.  This
> mechanism declares that the received file descriptors "behave as
> though they have been created using dup(2)".

That's the model we used. The problem with documenting it as such 
was ...

> There is no dup() in Java, so it appears we don't have a similarly
> universal comparison vehicle to fall back on in our definition.

... that it's very difficult to say without implying a platform 
dependency which isn't there, at least in the case of a single host 
implementation (eg. we're confident that it's implementable on top of 
Windows).

> I assume that a single process implementation on top of Unix should be
> able to use dup(2) (that's what I did in KaffeOS), so the semantics
> JSR-121 would need to define should be compatible with dup(2) for
> these environments.

That's what I did for the 1:1 implementation that's mentioned in some of 
the slides. The most invasive part of the changes I had to make to the 
standard Java runtime were to add support to the existing java.
{io,net,nio} descriptor bearing objects for passing across links.

> On the other hand, allowing all capability-carrying objects to be
> copied 1:1 with dup-like semantics has implications on what a
> cluster-based implementation can or cannot do.  Do we assume that
> such an implementation has to provide a strict single system image
> view?

Strictly speaking, yes, we do require a single system image (I'm pretty 
sure that's mentioned explicitly in the documentation). However, given 
that cluster implementations of Isolates are an open research area, 
it's probably not a bad thing that the semantics leaves a little wiggle 
room (my opinion, not necessarily shared by the rest of the EG).

> For instance, if a ServerSocket is transferred after a 
> bind/listen, should it retain its InetAddress?  What if it's
> transferred after bind and before listen?  For each possible
> semantics there are different implementation options.

It should behave exactly as it would in the Unix descriptor-passing 
case, ie. created as tho' using dup. In particular it should have the 
same source address if bound before passing (tho' not the same 
InetAddress object).

I'm not sure about the case where it's not bound before passing ... IIRC 
we punt that to the OS. I think we'd have to treat multiple receiving 
isolates independently binding to different addresses similarly to 
multiple receiving isolates setting different socket options ... ie. 
this is OS dependent, but the effect will probably that only the first 
bind will succeed, and the most recent set of options will apply.

Cheers,


Miles