The timeleak code is just a repro case. In real life I'm reading from
sockets as opposed to a file.
All I'm trying to do is run poker bots. They talk to the server and
play poker. Of course some events are more important than others, a
request to make a bet is more important than, say, a table update. I
do need to run as many poker bots as I can.
I think that my customer's goal of 4,000 bots is unattainable in a
single app. It's probably possible per machine. Overall, I find this
too complex to manage with Haskell as there are many factors that can
contribute to my delays and timeouts. There are also quite a few
unanswered questions at the moment (why is 'sequ' slow? does the
scheduler need to be tuned?) that leave me scratching my head.
On Jan 3, 2006, at 9:17 PM, S. Alexander Jacobson wrote:
You should be grouping incoming events into queues by expected
workload/event. Then you can give the client fairly reliable
information about how long it will have to wait based on the size
of the queue on which event is waiting.
And if you have no way to differentiate between event workloads a
priori then you really can't be giving clients response guarantees
and need to rethink your business logic.
--
http://wagerlabs.com/
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
