ANNOUNCE: PriorityChansConverger-0.1
Hello, cafe! Didn't find it in HackageDB, so made it. http://hackage.haskell.org/package/PriorityChansConverger Category: concurency Converges multiple channels into one. When user reads from the PCC, the choice is made - from which channel to read. System selects a nonempty channel, whose (CurrentPriority, StartPriority) tuple is max. The side effect of the channel selection is it's CurrentPriority decrease by one, if it's value becomes less than one, then the CurrentPriority is set to StartPriority. Based on STM.TChan, extended with capacity control. Version wrapped into is also available. The realization probably isn't very fast and isn't good at memory economy, since it uses fresh high level primitive - STM. It wasn't intended to be used with millions of channels. But it's max throughput comparing to the ordinary Chan throughput is to be estimated (will do it in some future version). Regards, Andrey Sisoyev -- View this message in context: http://old.nabble.com/ANNOUNCE%3A-PriorityChansConverger-0.1-tp26999572p2699... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
Hello Andrey, Sunday, January 3, 2010, 10:13:04 AM, you wrote:
thanks, it will be useful. one thing missing in announcement - whether it works in IO or STM monad? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
thanks, it will be useful. That's pleasant to hear, Bulat. =)
whether it works in IO or STM monad? I made both versions. PriorityChansConvergerSTM is made in STM in one module. And in another module STM version is wrapped into IO. The IO version is a buildup on top of STM version, and it has additional properties: (1) It (PCC in IO monad) uses MVar locks to secure system from "waste work". I thought, that transactions don't look too lightweight, so few bottleneck would be great... The negative side of this, is that asynchronous exception may cause loss of locks. Probably in a future version I will try to introduce more advanced locking mechanics, which will be secure facing async-excpts... (2) STM version has interruptableRead and interruptableWrite operations, whose interruption is controlled with parameter (STM Bool). IO version also has these operations + interruptables, that are controlled by parameter (Chan a, a -> Bool). I'm no sure if interruptables for IO monad are made optimal - they do spawn additional temporary threads, but I didn't see any better way to make this interruption.
Regards, Andrey -- View this message in context: http://old.nabble.com/ANNOUNCE%3A-PriorityChansConverger-0.1-tp26999572p2700... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
participants (2)
-
Andrey Sisoyev -
Bulat Ziganshin