09:22 am, 18 Sep 09
found my bug!
Not too interesting, but this has been bugging me for a week.
Been working on a toy program that proxies a TCP connection. It was working fine for some and then would mysteriously corrupt others; I spent a long time looking and it finally hit me, painfully obvious.
I had threads going in each way doing this in a loop:
Been working on a toy program that proxies a TCP connection. It was working fine for some and then would mysteriously corrupt others; I spent a long time looking and it finally hit me, painfully obvious.
I had threads going in each way doing this in a loop:
forward :: Socket -> Socket -> IO ByteString forward src dst = do buf <- recv src (16 * 2^10) send dst buf return bufNetwork.Socket.ByteString.send of course returns an integer of how many bytes were actually sent; you need to loop if you want to be sure to send it all. (I had imagined this higher-level API was handling this looping for me, but it makes more sense that it wouldn't. It does however handle
EINTR, so when I had glanced at the source in my desperation I did notice a loop, throwing me off the scent.) Sticking a loop around the send fixed everything.
But my vague understanding of GHC is that it has a rather esoteric implementation as far as languages go because of laziness. I would be pretty surprised if there was a stack involved. The paper "the spineless tagless g machine" discusses it.
They also do green threads (the runtime system only makes as many OS threads as you have cores) and I think I think I remember reading they can do millions of 'em, so it's again unlikely preallocated stacks are involved.