Experimental IRC log happs-2007-08-18

Available formats: content-negotiated html turtle (see SIOC for the vocabulary)

Back to channel and daily index: content-negotiated html turtle

These logs are provided as an experiment in indexing discussions using IRCHub.py, Irc2RDF.hs, and SIOC.

17:30:15<reltuk>I have a question about happs and it's handling of your applications internal state
17:30:57<reltuk>does your application have to process all requests sequentially? if not, how does HAppS merge the changes to the state that are happening in parallel?
17:36:36<Saizan>reltuk: it's based on software transactional memory
17:38:21<Saizan>reltuk: every request is processed in a transaction that changes the state atomically wrt the other transactions, just like in databases
17:39:30<Saizan>reltuk: STM is implemented directly in GHC, and exposed via the STM monad
17:40:24<reltuk>Saizan: so updating the state itself...this has to be done basically with a lock around the entire state object?
17:42:53<Saizan>reltuk: every update is written to a log, when the transaction ends if it has seen a consistent state then it's committed if not it's rolled back
17:43:43<Saizan>reltuk: so the STM implementation uses a lock to commit
17:47:59<reltuk>yes...I understanding (at least the principal of) STM...but the STM Var in HAppS is holding the entire application's state...there is no finer granularity with regards to "seeing a consistent state". So to my naive view it seems like it might be equivalent to writing a database-utilizing application that locks every single table in the database on every modifying transaction
17:48:53<alexj>reltuk: if you only have one CPU then this costs you nothing.
17:49:15<alexj>if you have multi-core: then it costs you nothing if the remaining cores are spent doing network stuff which is fairly common.
17:52:37<reltuk>alexj: given network/io latency, most single-core computers running network apps still benefit to a large degree from having multiple threads/processes processing request
17:52:41<reltuk>s/quest/quests/
17:54:07<alexj>agreed. so they all run in parallel accumulating events until they have a whole event arrived from the network.
17:54:32<alexj>once the whole event has arrived, it can be processed in-order atomically.
17:54:52<alexj>consuming/parsing events is done in parallel. delivering responses is done in parallel. only the state update happens sequentially.
17:57:36<reltuk>indeed...I suppose it's a small class of applications that see so many state modifying operations that it might result in that chain of waiting state changes growing faster than it's shrinking

Back to channel and daily index: content-negotiated html turtle