Andrew, Thanks for pointing your finger at it Am 04.08.2010 um 17:48 schrieb Andrew Coppin:
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? Yes, the transaction aborts and the application gets an exception (see remarks below).
- 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? Yes.
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. Ah, now I see. Excellent point. I was always focussing the commit case which is well designed, I am certain. But, maybe, the abort case above is not. It would probably be better to not only abort but also restart the transaction even in presence of a failure (that is what's being done when there is no failure). I am not quite clear yet about a possible implementation of such a behavior. Currently I'm thinking: Restarting a transaction containing broken TVars will definitely fail again. To avoid that, the validation vote of a broken TVar (i.e. not able to vote any more) should be taken as a valid vote and no exception should be thrown. Eventually every transaction comes to a commit and probably that's the only place where an exception should be thrown. Then the answer to your question is clear, also. Any opinions?
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...) Well, not quite. The name server gets a fixed 60000 to make it accessible statically, the others may vary. Their dynamic address is used to label the TVars which then always carry their correct address.
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? I have done a few tests with threads and could not find a significant difference. But I really did not look deep and thorough enough into it to give a qualified answer.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe