> > After upgrading to kernel 2.4.18pre7 (from 2.2.19), a recv() operation on
> > a UNIX socket returns 11 (EGAIN) even though the socket is blocking. My
> > code worked fine on 2.2.19.
> >
> > I am doing some more debugging to see why this happens but I would like to
> > ask whether anyone else has had similar problems? Is this a known bug?
>
> Not a known one. A small test case would be good
The problem was caused when my code tried to read 0 bytes from a unix
socket (my fault, didn't specifically check for wanting to read 0 bytes,
assumed recv() would just return 0 ...).
When there is no data available, the code blocks. If, however, data is
available, recv() returns EGAIN. Is this correct behaviour? In kernel
2.2.19, recv() did in fact return 0;
Test example below.
Matej
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <netdb.h>
#include <sys/types.h>
#include <sys/un.h>
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
int main(int argc, char *argv[])
{
char buf[1];
int s;
int retval;
struct sockaddr_un server;
if (argc < 2)
printf("Usage : test socketname");
s = socket(PF_UNIX, SOCK_STREAM, 0);
if (s < 0)
perror("socket :");
else
{
server.sun_family = PF_LOCAL;
strncpy(server.sun_path, argv[1], sizeof(server.sun_path));
if (connect(s,(struct sockaddr *)&server,SUN_LEN(&server)) < 0)
perror("connect :");
else
{
retval = recv(s,buf,0, 0);
if (retval < 0)
perror("recv :");
else
printf("Received %u bytes.",retval);
close(s);
return 0;
}
}
}
Matej Pfajfar
St John's College, University of Cambridge, UK
GPG Public Key @ http://matejpfajfar.co.uk/keys
Most people are good people, the rest of us are going to
run the world. -- badbytes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Feb 07 2002 - 21:00:29 EST