OTP or not to OTP

[Sean Hinde]

Jay,

> Adding in the max connection count for accepts has caused
> me some problems.  Once you start counting them, you must
> have everything linked or you won't know when the children
> go down.  Asynchronous processes end up off in their own
> world, while the gen_server's state is being updated.  When
> the asynch process needs to change state it can't because
> it is out of synch.  Also, I do have to worry about which
> processes can fail or not, so OTP didn't reduce any of the
> thinking or subtlety of the issues.

All of these things may be easily accomplished using a standard gen_server.
'EXIT' messages end up in handle_info, and you can use gen_server:cast()
variants to communicate asynchronously with the gen_server (and update its
state).

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. Otherwise it is the
same, and we use sys:trace and all the other good things all the time.


> I am starting to understand what Jocke and Joe are saying
> about OTP.  If you know it inside out, you probably wrote it
> and can work with it (or change it).  If you don't and you hit
> your head, you are struggling against OTP not erlang.  Once
> you take the leap and roll your own, you can modify it any
> way you want and you have finer control over issues like
> synchronization and state.

Take some time to study gen.erl and gen_server.erl. You will recognise the
structure from all the non OTP examples here and you can also see what the
experts have done about linking (they use monitor instead) and startup
synchronisation etc. Then decide whether you really want to roll your own in
every case.

> I wouldn't have considered doing it from scratch without the
> examples posted here in the last few weeks.  It also took me
> struggling to fit the concept into OTP to see where there are
> issues (there is a single gen_server state that must be
> updated synchronously -- asynch processes have to deal
> with that).  It feels like centralized management when I had
> the original impression that it was more like decentralized
> management.  Chris's new server / client library looks pretty
> clean (as does his whole toolbox approach).
> 
> On a team project I would want a standard that everyone adheres
> to and a separate architecture group.  It is very easy to get
> something 90% in erlang, but that last 10% has subtle issues.
> The simplicity of the code belies the issues that it solves.  Of
> course, in another language I wouldn't get far enough on a
> distributed problem to realize the issues that occur.

gen_server really works in most cases and has been designed to provide
exactly the framework you are after. I would be surprised if you didn't end
up re-inventing it almost the same if you made your own

Sean



 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.