[erlang-questions] gen_fsm and active sockets

Jani Launonen launoja@REDACTED
Thu Jan 17 13:21:42 CET 2008


Good (and well formed!) question from Dave and good aswers in the  
erlang-questions list!

There's one more alternative, namely plain_fsm behaviour by Ulf  
Wiger, which could be nice fit for the problem. It does away with the  
"complexities" of gen_fsm but still is suitable for supervision tree.  
Have a look at:

Jani Launonen

Dave Smith kirjoitti 15.1.2008 kello 20.51:

> Greetings,
> I'm using gen_fsm to manage a socket connection, and have a question
> about how one SHOULD use gen_fsm for this purpose. I'm specifically
> using the "active" mode for the socket, so I'm currently receiving
> events via the handle_info/3 callback. I understand why the socket
> events arrive there, but I wonder what the best way to pass the event
> along to the actual FSM is. I see there being 3 possible options:
> 1. Receive socket events on a dedicated process and pass events into
> gen_fsm via that process. Upside is that this provides nice separation
> of socket and fsm logic. Downside there is that I'm doubling the
> number of processes -- i.e. i had one process per socket, now I have
> two. That's not a big problem with a couple of thousand connections,
> but once I'm in the 20k-30k connections realm, I'm not quite sure what
> the implications of doubling the number of processes is. Is it
> "normal" in a production system to run 100k+ processes? Note: I'm
> still recovering from pthreads land, where 100k+ theads is a scary,
> scary thing -- so maybe this concern over # of processes is a
> threading world "hangover" :)
> 2. Receive socket events in handle_info and invoke
> gen_fsm:send_event() from there. This seems like the "obvious"
> approach, but it feels wrong -- I'm already in process and don't
> really want to queue up another event. Again, possibly a "hangover"
> from non-Erlang land.
> 3. Receive socket events in handle_info, then do a
> ?MODULE:StateName({socket_event ...}, State). Avoids (perceived)
> overhead of approach #3, but...is this a good idea?!
> Hopefully this isn't a stupid/obvious question -- I'm finding that
> erlang has a tendency to turn "common sense" on its head (in a good
> way). Any guidance from the gurus would be happily accepted.. :)
> D.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080117/b050040f/attachment.htm>

More information about the erlang-questions mailing list