Hello Joel, Wednesday, January 04, 2006, 12:42:24 AM, you wrote: JR> contribute to my delays and timeouts. There are also quite a few JR> unanswered questions at the moment (why is 'sequ' slow? are you tried to inline it? and all other pickling combinators the problem is what when you write put (Cmd a b) = do putWord16 a; putWord32 b and inline putWord16/putWord32, you can be sure that you will get sequencing for free. but what is a pickling combinators? it's a high-order functions, which combines drivers for simple types like Word16 to final driver which can read entire Command. the principial question - will this final driver be interpreted, i.e. executed as a large number of enclosed calls to pickler combination functions, or it will be compiled, i.e. executed as simple sequence of getByte calls, which then builds the final value. in first case your program will spend all its time in these combinator funtions calls, so you will not have much effect from using Ptrs in elementary picklers because of this issue i said you that pickler combinators can't guarantee performance, in constrast to Binary package which uses an artless approach to combine individual "picklers" - separate get and put fucntions so that each one becomes an straightforward imperative program as opposite to tuple carrying several functional values JR> does the scheduler need to be tuned?) try something like this: forever recvPacket withMVar global unzip unpickle runScript sendAnswer yield it will ensure that commands will be processed sequentially; i think it's the best you can do in this program: all tasks inside lock are cpu-bound, so it is better to finish them in one thread before going to another in production code you will also need to guard whole withMVar block with small timeout (say, 0.02s) -- Best regards, Bulat mailto:bulatz@HotPOP.com