[erlang-questions] should be a parallel tcp server, but can't connect to more than 1 client

[Christian S]

> The way I'd write accept_con (the way in the Erlang book) is like this:
>
> accept_conn(LSock) ->
>      {ok, Sock} = case gen_tcp:accept(LSock),
>      spawn(fun() -> accept_conn(LSock) end),
>      handle_conn(Sock).
>
> The way you write things is to silently swallow up the error return
> with no warnings, which make things difficult
> to debug since you get no indication of error. The Erlang way is to
> crash hard and early.

The phrase "programming for the successful case" describes this style
well. The only objection I have is that sometimes the bad_match exceptions
are not as informative as an explicitly-written crash reason.

I recently had to motivate why I liked erlang to some java-only
people, and mentioning
"crash early" does not vibe with them well. I think it is because they dont have
automatic restarting as an established approach in their gofy pattern-books.

I have to go into a longer discussion about windows machines, where
all problems, be it
the machine being slow or a service on it not responding or software
upgrade etc, are resolved by
control-alt-delete. And 2-3 minutes later things work better again.
Then getting them
to admit they have solved server problems like this for longer periods
(everyone has).
Then go on and explain how erlang takes this to a micro-scale. Where
restarts is the way
to handle all errors.  Since the costly thing is not the crash in
itself, but the time the service
is done.

This is my standard approach, using the insights i got from your
thesis. It makes them stop
asking more questions, but I dont know if it is because they are
convinced or because it is so
different that their brains stop.

If anyone have another approach to share, please tell.


Anyway, what I also wanted to say:
The 'iserve' webserver does things slightly different, the server
process is the only one that
spawns new acceptors, this requires acceptors to report back to it
when they have a connection
so the server can spawn the next one. I like this approach better.