| Age | Commit message (Collapse) | Author |
|---|
|
Add case to handle the situation when someone call
{gen_tcp,gen_udp}:controlling_process(Port, self()). Also improve spec
and doc from gen_udp and gen_sctp for controlling_process/2.
To reproduce the issue, open an UDP port:
4> {ok,Port} = gen_udp:open(9000, [binary]).
{ok,#Port<0.587>}
5> gen_udp:controlling_process(Port, self()).
ok
Simulate error:
6> 1=2.
** exception error: no match of right hand side value 2
Here is the leak:
7> inet:i().
Port Module Recv Sent Owner Local Address Foreign Address State
Type
581 inet_udp 0 0 <0.31.0> *:cslistener *:* BOUND
DGRAM
ok
|
|
The type is marked as a binary() or a string() but in practice it can
be an iodata(). The test suite was updated to confirm the gen_tcp/2
and gen_udp:send/4 functions accept iodata() (iolists) packets.
|
|
|
|
|
|
Currently an 8-tuple representing an IPv6 address is not accepted by
gen_tcp:listen/2, gen_tcp:connect/3,4, gen_udp:open/2, or
gen_sctp:open/1,2, unless the 'inet6' option is also given. This means
that an application that has obtained the address, e.g. from
configuration that allows for either IPv4 or IPv6, must always check the
type of the address before passing it to these functions. Letting the
functions infer 'inet6' from the 8-tuple, in case other options do not
override this choice, improves usability.
|
|
|
