Frank Kupke wrote:
Good questions. I am about to write a paper explaining the design of the DSTM library in more detail which I will link when available. Please bear with me, here. In the meantime please find some shorter answers below.
Well, that was pretty comprehensive. A few questions remain...
- If the failure comes up *before* the transaction has been validated ok, it is aborted.
Right. So the transaction rolls back and the application gets an exception?
- If the failure comes up *after* the transaction has been validated ok, it is committed.
So if a TVar goes walkabout in the split second between validate and commit, the others commit anyway, and then the application gets an exception? In that case, is there a way to determine whether or not the rest of the transaction completed? Because it looks like you can the same exception either way, regardless of whether a commit happened or not.
4. What network transport does this thing use? TCP? UDP? What port numbers?
DSTM uses TCP communication. It searches dynamically for available ports starting at port 60001, using 60000 for the name server. If two nodes are running each on a separate machine with a different IP address, chances are that both use the same port 60001. If they run on the same machine, most likely one will use port 60001 and the other 60002.
Right. So both the nameserver and any clients run on random port numbers? (Begs the question of how the clients figure out which port a remote nameserver is on...)
5. How does it work? Does it spawn a Haskell thread for each machine connection or something?
Each node spawns a Haskell thread listening to its designated port and spawning itself a thread for each accepted TCP communication, i.e. one for each foreign node talking to it. Each such thread implements a communication line between two threads. I have tried several communication line schemas which I will describe in more detail in the paper yet to come...
What impact (if any) does threaded vs non-threaded RTS have?