[Haskell-cafe] ANNOUNCE: DSTM 0.1.1

[Frank Kupke]

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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe