I don't want any kind of locking, true. I need all bots to respond in time otherwise the poker server will sit them out. Eliminating the timeout on pickling does not eliminate the timeout overall, it just passes it to a different place. One thread will go through serialization quickly but it will be too late by the time it sends a response to the server since it waited a few seconds for the chance to have a go at serialization. I'm trying to build 6.5 right now (having trouble, you might have guessed ;)) and will positively study the scheduler. I do not believe thread priorities are supported in GHC, though. I had a thought about using continuations but then I would also have to do selects on a few thousand file descriptors myself. Then I would have to decide which continuation to run based on priorities. I might as well patch the GHC scheduler to do what I need. Alternatively, I can just throw in the towel and rewrite the app in Erlang. I haven't made a firm decision yet, I think I will make my records storable first as you can't get "any closer to the metal". If that does not work then I will just give up. I do have other apps to write in Haskell but it will be a pity if this one does not work out. Thanks, Joel On Dec 21, 2005, at 9:12 PM, Cale Gibbard wrote:
Unfortunately, the way we have it here still affords no guarantees, it just serves as a mechanism to help keep things from getting too bad. It's unclear to me that you really don't want any kind of locking. I think that you might do quite well to decide which threads get to run yourself at least to some extent. After all, you know more about their priorities and how long they have to complete their tasks than the GHC scheduler does.