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

[Godmar Back]

Thanks.

Are these Miles personal opinions or the opinions of the EG, and if
the latter, could someone point me at where you documented your
reasoning?

Why did you discount the alternative of transferring the rights
associated with a capability?

 - Godmar

On Wed, 29 Sep 2004 08:45:57 +0100, Miles Sabin <miles@milessabin.com> wrote:
> 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
>