←back to thread

193 points ingve | 1 comments | | HN request time: 0.193s | source
Show context
michalsustr ◴[] No.43713518[source]
I’m not familiar with Haskell concurrency. The combination of green threads and large memory allocations due to immutable data structures sounds like it would be hard to implement a web server handling 10k+ concurrent requests on commodity hardware?

Btw. too bad author talks about microsecond guarantees usage but does not provide a link, that would be interesting reading.

replies(7): >>43713603 #>>43713615 #>>43713878 #>>43714039 #>>43715073 #>>43716268 #>>43724017 #
nesarkvechnep ◴[] No.43713878[source]
You obviously haven’t ran anything on the BEAM (Erlang’s VM).
replies(1): >>43714394 #
michalsustr ◴[] No.43714394[source]
Correct. Erlang also uses green threads?
replies(1): >>43715051 #
jlouis ◴[] No.43715051[source]
Yes. And immutable data structures.

When data is immutable, it can be freely shared. Changes to the data essentially uses copy-on-write. And it only writes the delta change, since you don't need a deep copy due to immutability. Add that the garbage collectors of Haskell and Erlang are designed to work with a high allocation rate and have 0 cost for dead data, and this is much faster than what people think.

The way you implement a webserver in either Haskell or Erlang is rather trivial. Whenever there's an incoming request, you make a thread to handle it. So you don't have 1 webserver serving 10k requests. You have 10k webservers serving 1 request each. And since they are started from the same core data, they'll share that due to immutability. See also old-style Apache or PHP and fork().

replies(1): >>43716589 #
eru ◴[] No.43716589[source]
Web servers handling lots of small requests are actually pretty easy to garbage collect to: you just delete all the data at the end of the request.

Either you have a specialised GC that works like this, or probably a good general generational GC can pick up on this pattern on its own.

replies(1): >>43723071 #
jlouis ◴[] No.43723071[source]
Or you do as Erlang's BEAM VM: each thread has it's own memory area which is GC'ed individually. This means upon request termination, you just terminate the thread and the memory is reclaimed with no need for a GC.
replies(1): >>43730534 #
1. eru ◴[] No.43730534[source]
In the abstract, this is very similar to spawning a unix process for every request, never free-ing any memory, and letting the memory allocation die with the process.