[erlang-questions] gen_tcp:controlling_process/2 impact

Jachym Holecek freza@REDACTED
Tue Aug 18 21:02:26 CEST 2015


# Fred Hebert 2015-08-18:
> On 08/18, Benoit Chesneau wrote:
> If the socket is used only for writing, then you don't need to
> change the controlling process, just send the thing directly. Anyone
> can write to a socket, just one process can read.
> 
> If you do need to read from it, then the best idea is likely to
> resolve your chain, find the final destination pid, and hand the
> control there.  The owner must hand the control, so rather than
> going:
> 
> a -- give --> b -- give --> c
> 
> go
> 
> a -- ask pid --> b -- finds --> c
> a -- give --> c

Just to give a more elaborate example of what Ferd is saying, from memory:

	accept 		peer 		connection
	proc 		server		proc
	-+---------------+--------------+---------
	 | 		 |
	 o 		 |				accept(L) -> S
	 |		 |
	 +---------------> 				add_connection(S)
	 | 		 |
	 | 		 +--------------> 		spawn(S, ...)
	 | 		 | 		|
	 <------------------------------+ 		reply(..., self())
	 | 		 | 		|
	 o 		 | 		| 		controlling_process(S, P)
	 | 		 | 		|
	 +------------------------------> 		handover_ack
	 | 		 | 		|
	 | 		 | 		o 		ready, active true

In Benoit's case there's more than one intermediary, but the overall picture
remains essentially the same.

> which will have a single control-handing form. You can also swap it
> around and let 'b' tell 'c' to "ask a for your port" and then do the
> switch.
> 
> Also remember to let the socket in {accept, false} mode so that no
> messages are lost during the whole operation.

One wants {active, false} here indeed. Let me add, just in case we're talking
protocol stack implementation, that it may turn out surprisingly convenient
to perform initial session setup with {active, false} using passive recv()
instead (intuitively one might lean towards {active, true} socket run by
a gen_fsm, which may end up nastily overcomplicated). It may also be very
convenient to do initial session setup from a different process (and
different code module) than where fully operational session is handled.

Not sure this makes an awful lot of sense without context, just reminded
me of something in my previous projects... Nevermind if not. :-)

Have fun,
	-- Jachym



More information about the erlang-questions mailing list