[Haskell-cafe] ANNOUNCE: PriorityChansConverger-0.1
Andrey Sisoyev
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-tp26999572p26999572.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Andrey Sisoyev
> 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-tp26999572p27002956.html