Advantages of a large number of threads cf other approaches?

[Andrae Muys]

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 
are similar.

> 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

-- 
  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