On Tue, Jan 03, 2006 at 04:36:37PM -0000, Simon Marlow wrote:
Is it impractical then to implement this type of app in Haskell? Based on the nature of Haskell scheduling I would be inclined to say yes.
Absolutely not!
Apart from the problem you have with a space leak caused by the input buffer of the logging thread overflowing, which is easily fixed by using a bounded channel, I don't know why you want priorities. Is there something else?
We could easily add Erlang-style priorities (though without the overhead of counting function calls, I'd do it by counting allocations), but I'd rather not if we can avoid it.
You could also achieve a similar effect without hacking the RTS, for example: track the number of elements in a Chan and on writeChan invoke yield with probability based on the number of elements in Chan - the more elements the higher the probability. You could experiment with different probability distributions. This is assuming that yield will make the thread wait for the next round. Best regards Tomasz -- I am searching for programmers who are good at least in (Haskell || ML) && (math || Linux || FreeBSD) for work in Warsaw, Poland