Advantages of a large number of threads cf other approaches?

[Sean Hinde]

On 18 Feb 2004, at 01:51, Shawn Pearce wrote:

>
> Well, given that erts is bound to a single processor, you would need to
> create a cluster of erts nodes, all running yaws, with some type of 
> load
> balancing front end.  This is one area Apache really shines in, as it
> easily allows this to be setup: because Apache is multi-process 
> already, it
> can easily share the single TCP server socket with all of its siblings 
> and
> decide who gets the next request.
>
> Does anyone think it might be possible to modify gen_tcp in such a way 
> that
> we could use multiple nodes on the same system all bound to the same 
> TCP port,
> and using some sort of accept lock between them?  I'd think this could 
> be done
> something like this:

This method was suggested to me earlier today in a completely different 
context but using UDP sockets. A strange co-incidence indeed.

For UDP sockets the documentation would seem to suggest an existing 
mechanism using the option:

"{fd,Fd}
If a UDP socket has somehow been opened without  using gen_udp, use 
this option to pass in the file descriptor for it and create a Socket 
for it."

But just getting the FD (using inet:getfd(Socket). ) and trying this in 
another Erlang node with gen_udp:fdopen(FD, []) doesn't work (probably 
obvious in hindsight).

The usage described to me earlier today is that 1 UNIX process opens 
the socket and then forks additional child processes which get access 
to the file descriptor. I guess that UNIX treats child processes in a 
special way (allows them to receive data on another processes FD).

Anyway. If it is possible this would be a VERY attractive way to take 
advantage of multiple CPU machines.

Anyone?

Sean