[erlang-questions] gen_tcp and processes receiving

Per Hedeland per@REDACTED
Fri Oct 5 08:15:46 CEST 2007


Fitzsimons <Bruce@REDACTED> wrote:
>
>Stephan Maka wrote:
>> Hi
>>
>>
>> I'm unsure about the use of gen_tcp:controlling_process when I simply
>> use a passive socket. Active sockets are no option here, I have strong
>> traffic shaping requirements.
>>   
>Your code starts working when you change the recv length to 0 (e.g. 
>unspecified) and stop expecting only one list elemet e.g. B instead of 
>[B].

No it doesn't - but it starts working when self() is evaluated in the
original process instead of in the spawned one, i.e.

@@ -12,12 +12,13 @@
                  "Host: www.erlang.org\r\n"
                  "Connection: close\r\n"
                  "\r\n"),
+    Master = self(),
     Pid = spawn_link(fun() ->
                              receive
                                  go ->
                                      ok
                              end,
-                             receiver(self(), Socket)
+                             receiver(Master, Socket)
                      end),
     ok = gen_tcp:controlling_process(Socket, Pid),
     Pid ! go,

>The documentation isn't crystal clear on this point as it says: "The 
>|Length| argument is only meaningful when the socket is in |raw| mode 
>and denotes the number of bytes to read." rather than something like 
>"The |Length| argument should only be non-zero when the socket is in 
>|raw| mode and then it denotes the number of bytes to read.".
>
>Your socket is not in raw mode so you'll need to manage excess bytes 
>yourself by buffering in a process if you want to process in 
>protocol-defined-chunks. I've not used raw mode but it may be appropriate.

But the socket *is* in raw mode in the sense referred to here, i.e.
{packet, raw}, since that is the ("obvious") default. Though of course
he should be using length 0 in any case, since 1 will be very
inefficient and any other value is unlikely to have the wanted behaviour
in this case (I think the manual is crystal clear on *that* aspect at
least, you just need to read it:-).

--Per




More information about the erlang-questions mailing list