On Sun, 2008-01-13 at 16:37 -0200, Felipe Lessa wrote: > On Jan 13, 2008 4:01 PM, Duncan Coutts <[EMAIL PROTECTED]> > wrote: > > On Sun, 2008-01-13 at 14:53 -0200, Felipe Lessa wrote:
> > Are you linking using -threaded or not? If not then you need another > > trick to use cooperative scheduling between Gtk and the RTS. > [snip] > > You must not be using -threaded then I'm guessing. That'd solve the > > problem. > > Actually I tried with all combinations of -threaded/not -threaded and > forkIO/forkOS. Use forkIO not forkOS. > I'm using an uniprocessor, but a simple turn-based game shouldn't > depend on dual-cores anyway =). Yes, those freezes do seem rather > strange, and when I introduced some (unsafePerformIO . putStrLn) with > the wall time they magically disappeared. Weirder. > I didn't try to pursue those little insects further because I got the > feeling that no mather what, they would come back. Is this unix or windows btw? > > > [...] using 'mainIteraction' [...] > > That's pretty ugly. I'd avoid that if I were you. > > Yes. =) > > > Here's my suggestion: use two threads. One thread for the game logic > and > > one thread for communicating with the user interface. [..] > It seems to be a nice idea. I worry about intermediate states that > shouldn't be observable (in my game the inputs the user is allowed to > give change over the time -- it's a board game, so which pieces can > move vary according to the current board), but what concerns me more > after that bad experience with only one forked thread are the delays > between the user giving an input ( e.g. moving a piece) and the > feedback being given (an animation of the result). The chain would be > something like > > input given --> processed --> new board created --> shown > (1) (2) (3) (4) > > So the interaction between the threads would be > > gtk: (1) ===\ /===> (4) > channel: \===\ /===/ > runPromptM: \===> (2) ===> (3) ===/ That should be fine. Haskell thread are quite sufficiently fast. The delays you're seeing are not because of general thread implementation slowness. > I'll try to code that ASAP and see how everything works together. If I > do observe the same delay problem, I'll try to at least reproduce it > on another machine and maybe create a simple test case. Good plan. If you're using -threaded make sure you really only ever call gui methods from event callbacks or within postGUISync/Async or things will go wrong in various random ways. In fact it might be a better idea to use the cooperative scheduling trick and make sure it works with the single threaded rts. > Other than that, I'm surprised you didn't comment about the last > solution, as that's where I'm currently heading. =) Oh sorry, I didn't get that far :-) It looks like it works a lot nicer so go with it :-). Remember, in general it is possible to switch between the console IO style where you're in control and the GUI event inversion of control style system. It's the thread/event duality thing. Duncan _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe