
Folks, My current setup involves threads that block on a MVar/TMVar until they read an event from it and then proceed. I would like to convert these threads into continuations whereby a continuation is saved when an event is requested and I can call that continuation when an even arrives. I had done this in Lisp before like this: (defun/cc receive (game) (let/cc k ;; save continuation (setf (continuation game) k) ;; TODO: start a timer here )) (defun/cc ask-for-blind (game amount context) (let ((posted nil) (seat nil) (active (car context)) (small-blind-p (= (small-blind$ game) amount))) (while (and (not posted) (car active)) (setf seat (pop active)) ;; skip people who are waiting ;; for the big blind if small blind ;; is being posted. (unless (and (waiting-for-bb-p seat) small-blind-p) (setf (state seat) 'sitting-out) (setf (current game) seat) (send (player seat) 'blind amount) (let* ((cmd (receive game)) <------- note the call to receive here (action (first cmd)) (bet (second cmd)) (inplay$ (inplay$ (player seat)))) ... How would this translate into Haskell and the Cont monad? Alternatively, I would appreciate an example that requests, say, two Ints by saving a continuation each time and returns the sum. Thanks, Joel -- http://wagerlabs.com/

Hello Joel, Friday, December 23, 2005, 12:49:19 PM, you wrote: JR> My current setup involves threads that block on a MVar/TMVar until JR> they read an event from it and then proceed. I would like to convert JR> these threads into continuations whereby a continuation is saved when JR> an event is requested and I can call that continuation when an even JR> arrives. hm... you are waste much time unsystematically "optimizing" random-selected parts of program. now it's time to stop jumping and start thinking the main mprovements drained by changing algorithms and not implementation details. profiling is only toold to know your program better but it can't replace careful planning and global vision. what you really need - is to ask questions about your global program structure instead of jumping between large number of techniques what you want to buy with continuations and, more important, why you need it? JR> Alternatively, I would appreciate an example that requests, say, two JR> Ints by saving a continuation each time and returns the sum. do a <- readLn :: IO Int b <- readLn :: IO Int return (a+b) or equivalent code readLn :: IO Int >>= \a -> readLn :: IO Int >>= \b -> return (a+b) amazed? :) -- Best regards, Bulat mailto:bulatz@HotPOP.com

On Dec 23, 2005, at 1:06 PM, Bulat Ziganshin wrote:
hm... you are waste much time unsystematically "optimizing" random-selected parts of program.
It's an assumption that you are making.
what you want to buy with continuations and, more important, why you need it?
To try to implement "thread priorities". I would like to use continuations instead of threads and pick the next continuation to run based on how much time it has to responde to the poker server.
JR> Alternatively, I would appreciate an example that requests, say, two JR> Ints by saving a continuation each time and returns the sum.
do a <- readLn :: IO Int b <- readLn :: IO Int return (a+b) [...] amazed? :)
Amused yes, amazed no. The code does not save a continuation after requesting each integer and does not allow me to call/cc it saved continuation with an integer of my choice. This is pretty much what I'm looking for: http://lisp.tech.coop/Web% 2FContinuation Thanks, Joel -- http://wagerlabs.com/

Hello Joel, Friday, December 23, 2005, 6:29:28 PM, you wrote: JR> It's an assumption that you are making. well, i may be wrong, but you also may be wrong :) just answer on my questions and see the results :) remember that i ask anything only because i want to help you
what you want to buy with continuations and, more important, why you need it?
JR> To try to implement "thread priorities". I would like to use JR> continuations instead of threads and pick the next continuation to JR> run based on how much time it has to responde to the poker server. but why the response times so long? it is because long startup time of each bot thread? if so, you need just to put lock around this stratup code. if not, any "thread priorities" will not help, i think. are you checked (by calculation) that with right priorities clients will not timeout? -- Best regards, Bulat mailto:bulatz@HotPOP.com

Bulat, I appreciate your offer of help but lets focus on the topic ;-). Thanks, Joel On Dec 23, 2005, at 5:42 PM, Bulat Ziganshin wrote:
Hello Joel,
Friday, December 23, 2005, 6:29:28 PM, you wrote: JR> It's an assumption that you are making.
well, i may be wrong, but you also may be wrong :) just answer on my questions and see the results :) remember that i ask anything only because i want to help you
what you want to buy with continuations and, more important, why you need it?
JR> To try to implement "thread priorities". I would like to use JR> continuations instead of threads and pick the next continuation to JR> run based on how much time it has to responde to the poker server.
participants (2)
-
Bulat Ziganshin
-
Joel Reymont