hhhhhhh @domi I said it before, you are great Thank you you always hits the target directly, Thank you for all I think this topic is fully answered.
2 Likes
Umm, sorry, I guess… I fear the answert to this will be even longer.
But, is it just my imagination, or did this conversation really pick up a somewhat hostile tune all of a sudden? If so, why? 
Ranch is a Network Layer Server and Cowboy is An Application Layer Server so we can use any Application Server on top of Ranch
Exactly. However, that was not the answer to your question, only a side note, with my point being that, since we’re talking accept strategies here, ie Network Layer stuff, we’re talking Ranch code, not Cowboy code. Sorry if I’m pedantic, but I think it is very important to be precise in what we’re talking about to avoid confusion.
my question was why using the Erlang implementation instead of the OTP implementation
It is still not clear to me what you are actually asking, sorry. What do you mean by “the Erlang implementation” and “the OTP implementation”?
I understood the question in your previous post as “Why is ranch_conns_sup not a standard OTP behavior (supervisor in this case) but a custom implementation?”, and this is what I answered fully and to the best of my knowledge, and what has been further elaborated by Loïcs talk kindly linked by @domi.
I could also read it to mean “Why is ranch_acceptor not a standard OTP behavior (gen_server in this case) but a custom implementation?”, and the answer would be that gen_server (or any other standard behavior for that matter) is really a poor fit there, like using an semi-trailer to deliver a small package to a house three doors away. The linked talk touches that too, I believe.
And I could also read it as “Why is ! used instead of gen_server:cast?”, and the answer would be that you can only use that to talk to a gen_server, but there are no gen_servers in Ranch (except for ranch_server and ranch_server_proxy, but they are a different topic altogether).
all recommandations from Joe and others said that should always use the generic server
Recommendations, yes.
It’s not that you should always do it, it’s more like that there is a heavy tradeoff to consider if you don’t, so you better have a very good reason and you know what you’re getting yourself into. In a nutshell: don’t make it a habit.
By creating a custom implementation, you may avoid a small performance penalty by removing some overhead, but you’re also sacrificing all the built-in conveniences and safeties the standard behaviors come with and thus have to re-implement at least some of them, thereby adding complexity and boilerplate code, and reducing overall maintainability.
Most of the time it’s just not worth it, the standard behaviors are usually a perfect/good/good enough fit.
But sometimes, like in the case of Ranch, it is worth it. And Loïc did an excellent job here in keeping things robust, understandable and maintainable despite using custom implementations in some places.
(when I said
gen_serverin my previous post I mean usinggen_serverinstead of the process created byproc_lib:start_linkI didn’t meanranch_conns_supso should read correctly my post)
Again I’m confused, what “process created by proc_lib:start_link” do you mean if not ranch_conns_sup? Because…
~/contrib/ranch$ grep proc_lib src/*
src/ranch_conns_sup.erl: proc_lib:start_link(?MODULE, init,
src/ranch_conns_sup.erl: ok = proc_lib:init_ack(Parent, {ok, self()}),
… ranch_conns_sup is the only process in all of Ranch that is started via proc_lib:start_link.
and I have posted a note from well know book previously
If you mean the quote from “Erlang Programming”, it doesn’t say anything about standard vs custom behaviors or when to (not) use which. Instead it says that you should use gen_server:cast+handle_cast instead of !+handle_info (termed “raw Erlang message passing” a few paragraphs before the quoted one) for (async) interaction with a gen_server.
and also the example from the book you mentioned (I read it a long time ago, you should read it before talk about)
You mean “Erlang and OTP in Action”? In fact, I did read it, albeit a long time ago. How else would I know what is written in there? That said, I didn’t say anything about the use of gen_server there, but about the use of the sequential (“naive”, as “Learn You Some Erlang” calls it) accept+spawn strategy.
I think to gain some performance taking off
gen_serveradditional overload as you said, if this is the case why we don’t all just taking off overload and taking off the OTP implementation ? in other terms when to be better to useproc_liband when to be better to usegen_server? this question is not easy to answer
IMO it is rarely worth even thinking about. As a rule of thumb backed by experience, I would always start with a standard behavior, and probe into custom implementations only if absolutely necessary, and then only very careful.
In an own project, all was working nice and smooth as long as I was sticking to the standard behaviors, but went rapidly downhill when I tried to be too smart and replace some standard with custom parts in an attempt to shave off even the last microsecond.
2 Likes
Published in 2010, it has acquired a little dust, but still a good read 
2 Likes
Hi @juhlig, there is any hostile but I replied as you did,
in fact when I said that I didn’t read the entire code you didn’t respect me (“you’re mixing things” , “you are not entirely off”,…), and in the same time you didn’t give me any help except doing stuff for Ranch (as you said), so I think it’s my right to reply to it.
1 Like
Here Erlang brings us together, so I think should never disrespect someone, and the more important should be professional so,
I read the slides from @domi link but should read it again to better understood, the author said about using spawned processes instead of behaviours to get some performance in some cases and taking off recommendations that say all the time that should use OTP behaviours (he even talk about Cesarini’s recommendation that I posted previously), but he didn’t explain it in details because it was just abreviated slides, and the most important part from using spawned processes instead of behaviours is to avoid a monitoring process that monitors the gen_server because this server is already monitored and tracked by it’s supervisor
1 Like
I’m really sorry if I came about cross, I really didn’t mean and it never even occurred to me that it could be taken that way 
Peace?
When I said “you’re mixing things”, I wanted to prevent confusion. Cowboy is huge and complicated compared to Ranch, and it is not the right place to look when the subject is accept strategies. Obviously, you were looking at the Ranch code, but you kept referring to it as the Cowboy code, so I just wanted to set things straight there. Know what I mean?
And when I said “you’re not entirely off”, this was because you were asking something referring to gen_server, but somehow I was under the impression that your question actually concerned ranch_conns_sup, which mimicks the supervisor behavior, not gen_server. But then again the supervisor behavior is itself an implementation of the gen_server behavior, which in a sense brings gen_server back in the picture.
Finally, when I said I was “doing stuff for Ranch”, well… It was the first open source project I ever contributed to and for a long time. Over the years I had many discussions with Loïc on IRC, and I learned a lot from him. But in all that time, it never occurred to me to ask him why ranch_conns_sup was not a proper standard supervisor. It would have been a valid question, but for some reason I just took it for granted.
Again, sorry for expressing myself badly 
Fun fact, in my company they don’t let me talk to customers directly because even if I make an effort to be extra nice with a cherry on top, I somehow come across offensive. So they make sure to always put some nice support/customer care people between me and customers, to sugarcoat what I might be unwittingly saying 
3 Likes
Yes, I noticed… I rummaged around for a bit and found a video recording of the talk which might prove more helpful 
2 Likes
You are welcome @juhlig 
there is nothing it’s just misunderstanding and me too Iam so sorry if I said something that hurt your feelings we are humans and we constantly make mistakes but I want to confirm that I don’t hold any grudge to any one here and all that I want is to share informations that every Erlanger can benefits from it as we do, I hope that we talk again in another post so good evenning, Erlang brings us together.
3 Likes
I’m very glad that we could clear up that misunderstanding 
No hard feelings, looking forward to talk to you in another thread
5 Likes