I've been tinkering in the boss router a bit lately, and you're right about how the use of a gen_server guarantees atomicity.
But at the same time, a gen_server does present a potential bottleneck. Frankly, I've been thinking the router controller might benefit from having the router configuration either compiled into an actual module (like how erlyDTL compiles html to a module), or using a routing handler, either of which effectively removes that potential for a bottleneck, and reloading the module with Erlang ensures atomic changes to the routing system. Personally, I like the routing handler idea myself, as it requires less screwing around with compiler magic and also would make the router more flexible (more powerful than just regular expression matching). But it also makes the configuration a little longer. I still think it's a worthwhile tradeoff. -Jesse -- Jesse Gumm Owner, Sigma Star Systems 414.940.4866 || sigma-star.com || @jessegumm On Jun 9, 2014 8:16 AM, "rambocoder" <[email protected]> wrote: > An OTP question... > > In boss_controller.erl which is a gen_server instance, let's say multiple > processes send "reload" atom to the gen_server > > > https://github.com/ChicagoBoss/ChicagoBoss/blob/master/src/boss/boss_router_controller.erl#L52 > > which does a sequence of steps: > > ets:delete_all_objects(State#state.routes_table_id), > ets:delete_all_objects(State#state.reverse_routes_table_id), > ets:delete_all_objects(State#state.handlers_table_id), > load(State), > > > do the "reload" messages just que up and handle_call acts like a mutex > around these sequential steps? > > I was thinking on how to speed up routing in boss_controller, does it need > to be a gen_server with all the contention around 1 process because all the > routing data is stored in ETS, but then I notice that the > boss_router_controller gen_server acts as a mutex to provide atomic > manipulation of the routing tables in ETS. > > Is boss_router_controller the best way to store and access routing info? > > Cheers, > > -rambocoder > > -- > You received this message because you are subscribed to the Google Groups > "ChicagoBoss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > Visit this group at http://groups.google.com/group/chicagoboss. > To view this discussion on the web visit > https://groups.google.com/d/msgid/chicagoboss/99d3f555-d07f-4ae2-9582-da818856216e%40googlegroups.com > <https://groups.google.com/d/msgid/chicagoboss/99d3f555-d07f-4ae2-9582-da818856216e%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "ChicagoBoss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at http://groups.google.com/group/chicagoboss. To view this discussion on the web visit https://groups.google.com/d/msgid/chicagoboss/CAPTXyXcRLi_J44exT5qU%2BQWKoFA9K0_b4jDn8VKOZpJc1T%3DyBg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
