sql__quasiParser: intervat/concurrency matters

On Mar 11, 2010, at 11:31, John Carlson wrote:

> Any thought on making sql_quasiParser objects communicable across  
> vats?

This is feasible by way of pass-by-construction. The real  
sql__quasiParser would be marked pbc and have an optUncall method[*]:

  def sql__quasiParser implements pbc {
    to __optUncall() {
      return [makeSQLQuasiParser, "run", [connection]]
    }
    to valueMaker...
  }

The database connection object (unless it is itself pass-by- 
construction, which might be reasonable to add if the connection is  
stateless) will be received as a far ref in the original vat. The  
sql__quasiParser is revised so that *if* the connection is a far ref,  
*then* it will make eventual sends to it.

The necessary consequence of this is that the iterate/1 can't be  
invoked immediately since the data isn't there yet; the cleanest way  
to do this and let the client handle it correctly is that substitute/1  
returns a promise for the sqlResults object. (I'm only considering the  
SELECT, not UPDATE/etc cases.)

Actually -- In order to preserve E's turn isolation and non-blocking  
characteristics, you probably need to wrap database connections  
(either as far refs or wrappers which run the executeQuery etc in  
another thread and return promises); not wrapping them violates E  
semantics. This is true with or without adding the above inter-vat  
functionality.

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>