Re: Various E patches

On Tue, 2010-04-13 at 11:43 -0400, Kevin Reid wrote:

[ database quasi-parser ]

> This is a good point. In particular, since Java has an official SQL  
> API, E-on-Java should include appropriate wrappers for it. I retract  
> my objection on these grounds.
> 
> Have you fixed the synchronous access/determinism issues I previously  
> mentioned in
>    <http://www.eros-os.org/pipermail/e-lang/2010-March/013486.html>
> ?

I think that access to a database connection is sufficiently powerful
that trying to prevent non-determinism at this level is pointless. After
all, SQL is itself non-deterministic. e.g. the rows returned by a SELECT
can come in any order (unless you put an ORDER BY on the end).

In other words, you will always want to provide a Database Access Object
that provides an application-level interface with sensible E semantics.
For example, our wrappers only ever do queries with an ORDER BY, but
they are synchronous because our database is local and only accessed by
a single vat.

Making the calls asynchronous would cause problems in many cases.
Remember that a "database" is not necessarily a remote service. It can
quite easily be a local file accessed directly from the JVM (this is how
I use it) or even just an in-memory object.

So, I see SQL access as similar to <file> access in E: synchronous and
immediately subject to changes by other vats, to be wrapped where
needed.

> >>> * Share a single SafeScope within each vat
> >>
> >> This sounds like the right thing. Where is it stored?
> >
> > Each ImportLoader creates and stores one (since there's already one
> > ImportLoader per thread, and it's the thing that uses it).
> 
> Sounds reasonable. I'd like to take a closer look at it for  
> inappropriate dependencies, though. Unless MarkM can get to it sooner.

OK, will wait until next week before committing.

> >>> * In "not synchronously callable" error, give the verb
> >>
> >> E-on-CL generates "not synchronously callable: rec.verb(args...)" for
> >> the message. The implementations shouldn't be gratuitously different
> >> in this regard. Do you have a rationale for not printing the other
> >> components?
> >
> > Just the general issue of error messages leaking information. I'm a  
> > bit
> > concerned about ex.eStack() showing the arguments too, though it's
> > certainly useful.
> 
> eStack has enough information that you're utterly doomed.
> 
> Unfortunately there isn't a design issue page for it on the wiki, but  
> the solution is that *every* throw()n exception object, or  
> equivalently exception object you get from a catch block, is sealed.
> 
> Besides the debugging information, the throw-catch itself is  
> *dynamically scoped* and therefore does not follow capability  
> semantics; so we seal the information so that the only information a  
> catch give is 'unexpected failure within'.
> 
> Only that with debugging access can see either the message or the  
> eStack. Of course the REPL will automatically do that.
> 
> E-on-CL contains a partial implementation of these semantics.  
> Unfortunately, there's no formal writeup of the whole thing that I  
> know of, but there's some discussion in the mailing list archives.
> 
> http://www.google.com/search?q=site:eros-os.org+sealed+exceptions
> 
> If you'd like to help implement these semantics, please do -- it's one  
> of the big security problems currently in E-on-Java for untrusted-code  
> purposes, and one of the things that needs additional design work and  
> experience with Real Applications which need to do things like logging  
> errors.

OK, thanks for the clarification. What is the stack trace supposed to
look like once the E-to-JVM bytecode compiler is implemented? I guess
arguments won't be visible then anyway?


-- 
Dr Thomas Leonard
IT Innovation Centre
2 Venture Road
Southampton
Hampshire SO16 7NP

Tel: +44 0 23 8076 0834
Fax: +44 0 23 8076 0833
mailto:tal-v5nx5w6akNyLE8xUarVfuPLx9OUvmyODWmv/[email protected]
http://www.it-innovation.soton.ac.uk