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

Serge Aleynikov <>
Sun Oct 7 15:52:24 CEST 2007

I was playing with Scott's Unix Domain Socket driver from jungerl and 
ran into the following issue.

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 

Here's the synopsis using unixdom_drv:

1> {File, Server} = {"/tmp/sock", 1}.
2> {ok, Port} = unixdom_drv:start().
3> {ok, US} = unixdom_drv:open(Port, File, Server).
4> {ok, FD} = unixdom_drv:getfd(Port, US).
5> {ok, Sock} = gen_tcp:listen(0, [binary,{packet,2},{fd,FD}).
6> gen_tcp:accept(Sock).
[... In another terminal window do: unixdom_drv:open(Port, File, 0) ...]
{error, einval}

The root of the issue is here (that is the call made by prim_inet right 
after successful async_accept):

7> prim_inet:getopts(Sock, [priority]).
8> prim_inet:setopts(Sock, [{priority,0}]).
{error, einval}

Apparently unix domain sockets don't support this option.  I would think 
that one workaround would be to clear this priority option on the 
listening socket prior to calling gen_tcp:accept/1, but I don't see a 
way of doing so.

It seems to me that the list of default options in 
prim_inet:accept_opts/2 needs to be able to be customized by the caller 

Any suggestions?


More information about the erlang-questions mailing list