continued init (RE: OTP or not to OTP)

[Sean Hinde]

> On Mon, 3 Mar 2003, Sean Hinde wrote:
> 
> >The main tcp/ip server model we use in our systems is made
> >of 2 gen_servers. The only difference to the 'pure' erlang
> >version is that the startup of the accepting gen_server
> >process is made slightly more complex. The init function
> >sends a message to itself to start up the accept call in
> >the main callbacks otherwise the starting process would
> >hang.
> 
> 
> Some people will probably want to strangle me for revealing
> this "secret", but you can actually do this:
> 
> start_link() ->
>    gen_server:start_link({local,myserver},?MODULE,self(),[]).
> 
> init(Parent) ->
>    ...,
>    proc_lib:init_ack(Parent, {ok,self()}),
>    State = ...,
>    {ok, State}.

Well, we get away with it in our tcp server because the client is going to
be the other end of the new socket which is only created when accept
returns, and by that time we have consumed the message to ourselves and are
ready to go.

But yes, otherwise you are correct of course. I do believe that we are
slightly kidding ourselves when we say that Erlang makes concurrent
programming easy* - it is easy (ish) to make simple 'object' type processes
but it is possible to get into an enormous mess of deadlocks and so on if
you try to get too tricky. This to me is another reason why gen_servers and
so on are a good thing - they stop people trying to get too complex and then
find that after a couple of months some weird network conition occurs which
deadlocks the whole thing.

Sean

* Vastly easier than the pthreads type model favoured elsewhere of course,
but still not VB easy



 NOTICE AND DISCLAIMER:
This email (including attachments) is confidential.  If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents.  We cannot accept liability for any breaches of
confidence arising through use of email.  Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions.  We will not accept responsibility for any commitments
made by our employees outside the scope of our business.  We do not warrant
the accuracy or completeness of such information.