On Mon, Apr 18, 2011 at 07:55:57AM -0400, Mike Meyer wrote:
On Mon, 18 Apr 2011 12:56:39 +0200 Ertugrul Soeylemez <es@ertes.de> wrote:
You also don't need Emacs/Vim, if all you want is to write a simple plain text file. There is nothing wrong with concurrency, because you are confusing the high level model with the low level implementation. Concurrency is nothing but a design pattern, and GHC shows that a high level design pattern can be mapped to efficient low level code.
Possibly true. The question is - can it be mapped to a design that's as robust and scalable as the ones I'm used to working on?
I have not written any such server so take my response with a pinch of salt but I believe that the forkIO based solution does indeed scale to 10K clients. Internally the runtime uses epoll or kqueue to simulate the concurrency, so I don't see why it should be slower. May be you can check with the developers of Network.Wai or the Happstack server developers. They might be in a better possition to explain.
[snip]
Perhaps Haskell is the wrong language for you. How about programming in C/C++? I think you want more control over low level resources than Haskell gives you. But I suggest having a closer look at concurrency.
Personally, I don't want to have to worry about low-level resources, or even concurrency. Having to do so feels to much like having to explicitly allocate and free memory, or worry about register allocations. But if I have to do those things to get robustness and scalability until the languages start being able to deal with it, then I need the RTS to get out of the way and let me do my job.
I think it would be good idea to prototype what you want to do and have a try. Most likely I would think you would be surprised with the efficiency.
If I'm using a value that needs protection from concurrent access without providing that protection, I want the system give me an error. At run-time is acceptable, but compile time is better.
Try STM's. They are great abstractions for shared states. Regards ppk