Advantages of a large number of threads cf other approaches?
Thu Feb 19 03:53:24 CET 2004
Shawn Pearce wrote:
> Some UNIX variants have a "feature" (bug) where it wakes up multiple
> processes, telling them a UDP packet or new TCP connection is available.
> The processes come out of select/poll, hit read/accept and more than
> one of them gets the same TCP socket or the same UDP packet. Now you
> have more than one node attempting to process the data, and you may
> generate two different replies when only one was necessary.
> I guess you could try to have the Erlang nodes elect who will handle
> the connection/packet that just arrived, but there is no way for
> them to know if they have duplicates or not. So life could get
> ugly. But if the gen_tcp/udp drivers support dynamically enabling
> disabling the server socket from the erts event loop, life is ok.
Not entirely correct. The semantics of accept() guarentee only one
return across the multiple children. The 'wake-one' semantics offered
by various unixen is strictly an optimisation to avoid the cache/process
thrashing involved when multiple children wake up in response to a
connection and then all-but-one immediately wait-on-accept. So there is
no chance of duplicates, or multiple replies. Only one node will
actually recieve the connection.
Note that for UDP you don't call accept, you generally call recv, or
recvfrom. However I believe the semantics regarding simulataneous calls
> This would work very well on a multiple CPU machine, as each CPU
> can have its own dedicated node, epmd+normal erlang monitoring can
> be used to know state of the other nodes, and life is very sweet.
> So how about it? :-)
Andrae Muys <andrae.muys@REDACTED>
Engineer Braintree Communications
"Now, allowing captured continuations to be inspected and altered at
runtime (including binding mutation, complete rebinding of scopes,
and call tree mutation)... *that* is really evil. And, I should
point out, quite useful." - Dan Sugalski
More information about the erlang-questions