[erlang-questions] gen_tcp:accept use within a gen_fsm process

Ulf Wiger (TN/EAB) ulf.wiger@REDACTED
Mon Jun 25 16:43:05 CEST 2007


You can pass along e.g. the parent pid to the 
init/1 function, then use 

 proc_lib:init_ack(Parent, {ok, self()}

then perform your blocking call, and then:

gen_fsm:enter_loop(Module, Options, StateName, StateData, FsmName)

See the documentation on gen_fsm.

The enter_loop() function was introduced specifically
for this kind of thing.

BR,
Ulf W
 

> -----Original Message-----
> From: erlang-questions-bounces@REDACTED 
> [mailto:erlang-questions-bounces@REDACTED] On Behalf Of igwan
> Sent: den 25 juni 2007 13:42
> To: erlang-questions@REDACTED
> Subject: [erlang-questions] gen_tcp:accept use within a 
> gen_fsm process
> 
> Hello list,
> 
> I'm writing a small TCP test application. I want each TCP 
> connection to be handled by one gen_fsm process. I could have 
> one 'acceptor' process calling gen_tcp:accept, then spawning 
> a gen_fsm for each accepted incoming connection. But in the 
> doc, I read that, since a recent version of Erlang/OTP, I can 
> have any number of processes waiting in a gen_tcp:accept 
> call, so I wouldn't need the acceptor process anymore. My 
> question is about best practice. Where would you call 
> gen_tcp:accept in the gen_fsm module ? Into the init/1 
> function ? Like this :
> 
> -module(tcptest_fsm).
> -behaviour(gen_fsm).
> 
> init([Listen_socket] = Args) ->
>     {ok, Socket} = gen_tcp:accept(Listen_socket),
>     ...
>     {ok, conn_accepted_state, SD}.
> 
> 
> I'm not very confident about puting such a blocking call at 
> the init phase as the process wouldn't be initialized until a 
> connection arrives and thus not supervised (Am I right ?).
> Or maybe the new possibility offered by gen_tcp:accept wasn't 
> intended for use within a OTP system ?
> 
> Thanks for your help.
> 
> igwan
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
> 



More information about the erlang-questions mailing list