Tom, your NV stuff is interesting. (I think it should be called NetV
though, to eliminate any confusion with NSV.) I don't understand the
bit about the tcp pool on the client side having a mutex around it
though, what for?
It should be interesting to see what the performance looks like.
(Obviously it's going to be much worse than nsv using process-local
memory, but probably plenty good enough for many or most
applications.) I wonder if UDP might work better than TCP; but then
there's no UDP access from Tcl, so certainly ignore that idea for now.
You probably need to worry about handling broken tcp connections in
the pool - Cleverly's
could be helpful for that.
The enhanced nsv/tsv provided by the Tcl Threads Extension might be of
particular value, as in some cases it's more powerful API let's you do
more work in a single atomic call, which means only one round trip to
the server rather than several. Also, in order for NetV to work the
same as NSV, you need NetMutex too, otherwise it's impossible for the
client to properly serialize access when doing complex operations on a
Nsv. That's also a good reason to use the Tcl Threads Extension
tsv/nsv rather than the legacy AOLserver nsv implementation, as it's
enhanced API should let you avoid explicit use of mutexes much more
You may also want some sort of notification from the server to the
client, saying, "Oh shit, I just crashed and restarted!". Edge cases
like that are never going to work quite the same way as local Nsvs,
but that should be ok.
This NetV stuff is all basically a re-invention of the
stuff of course. That Wiki page also mentions that Ruby ships with a
standard tuplespace implementation, so it might be worth looking there
briefly for any lessons learned, performance hacks, or that sort of
If you ever had a site making really big use of NetV (like AOL Digital
City, say), I wonder whether it would pay to have NetV do its message
passing over the network via MPI rather than straight TCP sockets. As
long as the MPI is still talking over TCP/IP underneath, my guess is
no, as the NetV communication patterns are very simple. But if you
had an alternate low-latency ethernet driver (no TCP/IP, OS bypass,
etc.), MPI might be the easiest way to interface to it (because
someone else will have already done the work). And of course, if for
some bizarre reason you actually had an SCI interconnect between your
boxes, like you'd need for
you could use the real SCI shared memory for NetV too. (All very very
blue sky, this whole last paragraph.)