[erlang-questions] prim_inet:accept() bug with {fd, N} socket option?

Serge Aleynikov <>
Mon Oct 8 03:32:36 CEST 2007

Per Hedeland wrote:
> Serge Aleynikov <> wrote:
>> gen_tcp:connect/2, gen_tcp:listen/2 functions expose an option {fd, 
>> FileDescriptor} that allows to take an elsewhere opened file descriptor 
>> and make it usable in the gen_tcp module.  This is a very convenient 
>> option, however, what I discovered was that the default options that are 
>> being set on a socket by prim_inet:accept_opts/2 call involved in 
>> gen_tcp:accept/1 try to get/set a 'priority' option that may not be 
>> supported
> Well, it's rather dubious to pass in a non-inet socket to the inet
> modules/driver, 

What else would be the use of the {fd, N} option in gen_tcp:connect/2, 
gen_tcp:listen/2?  I would think that Unix Domain Sockets (UDS) is a 
rather good example or else one would need to mirror all 
gen_tcp/inet_tcp/prim_inet functionality to support UDS.

Ideally the inet_drv along with gen_tcp/inet_tcp/prim_inet would be 
extended to be able to support UDS on Unix-like platforms.

> but anyway the problem you're running into isn't really
> that 'priority' isn't supported (SO_PRIORITY is a Linux-specific thing
> AFAIK, but it's a socket-level option and so works for any type of
> socket), but rather that the driver does some pretty ugly things in an
> attempt to make 'priority' and 'tos' appear to be independent, even
> though they aren't at the OS level (it's a mistake to do this I think,
> but let's ignore that for the moment).

Ah, I suspected that after reading comments in setopt_prio_tos_trick(). ;-)

> This has the effect that it ends up trying to set the IP_TOS option on
> your unix-domain socket, which doesn't work of course, and then it gives
> up on the whole thing even though it was actually SO_PRIORITY that was
> requested (from the prim_inet code you quoted).
> Below is a patch that addresses this - it's against R10B-10 though, and
> won't apply against current versions since even though the code is
> essentially the same there, it has moved around a bit. But maybe you can
> convert it - or just comment out the whole setopt_prio_tos_trick() thing
> there.:-)

Thank you very much, this is very helpful!

> I have subsequently hacked prim_inet and inet_drv to handle arbitrary
> non-inet sockets "properly", i.e. allow for passing in 'unspec' (as in
> AF_UNSPEC) as the address family, and in that case refrain from doing
> *any* AF_INET/AF_INET6-specific get/setsockopts, as well as
> getsockname() and getpeername() (since the address format is unknown).
> It's perhaps still a bit dubious to "abuse" the inet code this way
> though, but you sure get a lot of stuff for free that way...

Perhaps you could send these patches as well and the OTP team could 
consider including them in the distribution?



More information about the erlang-questions mailing list