The memory allocation / threadDelay 0 has no effect, so it isn't <i>that</i> bug. <div><br></div><div>I've noticed something new, too. I have some other sleeping threads in the system. When those sleep for short threadDelays compared to the frequency of accepts, the problem is accelerated. However when the other threads have threadDelays that go longer than the accept frequency, the problem doesn't seem to occur. <div>
<br></div><div>That is, it seems that having pending thread-awakenings prevents the issue. I'm stumped!<br><br><div class="gmail_quote">On Thu, May 13, 2010 at 3:51 PM, Daniel Fischer <span dir="ltr"><<a href="mailto:daniel.is.fischer@web.de">daniel.is.fischer@web.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Thursday 13 May 2010 21:28:21, Aran Donohue wrote:<br>
> I have an accept-loop:<br>
><br>
> do (conn, _saddr) <- accept sock<br>
> forkIO $ initializeConnection conn<br>
><br>
> Which allocates memory iff accept allocates, I suppose. To test the<br>
> theory, is there a way I can force an allocation that won't get<br>
> optimized away?<br>
<br>
</div> t <- getCPUTime<br>
let n = t `rem` 12345<br>
s = sum [1 .. n]<br>
s `seq` doSomething<br>
<br>
could work.<br>
<br>
Another option is to insert a<br>
threadDelay 0<br>
in your forever loops to enable context-switching if some other thread is<br>
runnable.<br>
<div><div></div><div class="h5"><br>
><br>
> I'm not quite sure how I ought to proceed. I'm still very open to<br>
> debugging tools and techniques I could use to approach the problem!<br>
><br>
> Aran<br>
</div></div></blockquote></div><br></div></div>