The server program supports long TCP connections with many clients. Each client connection is served by a thread created with forkIO. The server works with a lot of memory at work, so naturally, I did profiling to track down possible space leaks. However, having about 10 thousand clients (therefore, flows of 10 thousand), the result shows that the main part of the heap is actually STACK allocated by flows. If I understand correctly, this is not surprising, since the flow stack starts with 1k by default and increases by 32 thousand pieces. Since these are long threads, this memory will not be GCed.
My question is: STACK takes up too much space, is there any way to reduce it?
I had some thoughts about this: Earlier, I could use the GHC event notification APIs to write a program without using threads, however it seems that this option is no longer possible because GHC has stopped exporting some event processing functions, such as loop. On the other hand, such a change means a big shift in the concurrency model (threads against events), which is very undesirable, since Haskell threads are simply pleasant to work with. Another way that came to my mind is to split / rewrite the streams so that one stream executes all confirmation + authentication files, creates a new stream and then exits. A new thread that will continue the loop, hopefully does not require more STACK space. However, I am not sure if this idea is correct or feasible.
