On Sep 15, 2009, at 12:02 PM, Matthew Scott wrote:

>
> This could pose a "handoff" problem, where in process A (an
> application) starts the Durus server, process B (a Python shell
> inspecting some things under the hood) connects to the server
> started by process A, then A shuts down, taking the Durus server
> with it, now process B is left hanging without Durus.

I think this could be addressed by forking and having the parent run
the server so that the server still has
a live parent when the client quits.

>



> This can be done, but it sounds easier than it really is.  You'll
> need to
> read the tail, find the oids, and make sure that none of them have
> states
> loaded in your cache during this transaction.  It isn't enough just to
> look for conflict with the oids you are writing.  This could
> potentially be
> a slow operation, and it has a cost that the server-based durus
> avoids.
>
> I'm guessing that using a Durus server avoids this because the Durus
> server keeps such information in memory?

Yes, the server keeps track of the oids as it writes and makes sure
that they are all delivered back to clients when
they ask for invalidations.

>
> I can see where this would be a slowdown across several processes.
> If 4 processes are working on the same file, and one of them writes,
> then 3 processes now have to read+process the tail.

Yes.

>
> So, rather than read and invalidate on each file length change, we'd
> just "pretend" that the file isn't growing at all, and perform an
> analysis on a snapshot of the database.  When the client code was
> finished, it would call continue(), at which point the database
> state would be allowed to sync with latest changes -- client code
> wouldn't care though, since it is done with its analysis.

That  behavior is okay, as long as the client has nothing to write,
and doesn't really care about being perfectly up-to-date.
If the thing that I miss is the sale of my seat to someone else, I'm
unhappy.