jeff.polakow: > We have a server that accepts messages over a socket, spawning threads to > process them. Processing these messages may cause other, outgoing > connections, to be spawned. Under sufficient load, the main server loop > (i.e. the call to accept, followed by a forkIO), becomes nonresponsive. > > A smaller distilled testcase reveals that when sufficient socket activity > is occurring, an incoming connection may not be responded to until other > connections have been cleared out of the way, despite the fact that these > other connections are being handled by separate threads. One issue that > we've been trying to figure out is where this behavior arises from-- the > GHC rts, the Network library, the underlying C libraries. > > Have other GHC users doing applications with large amounts of socket usage > observed similar behavior and managed to trace back where it originates > from? Are there any particular architectural solutions that people have > found to work well for these situations?
Hey Jeff, Can you say which GHC you used, and whether you used the threaded runtime or non-threaded runtime? -- Don _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
