Messages in this thread | | | Date | Wed, 17 Nov 2004 16:29:14 +0100 (CET) | From | Catalin Drula <> | Subject | AF_UNIX sockets: strange behaviour |
| |
Hi,
I have a small application that communicates over Bluetooth. I use connection-oriented UNIX domain sockets (AF_UNIX, SOCK_STREAM) to communicate between the applications's threads. When reading from one of these sockets, I get a strange behaviour: if I read all the bytes that are available (13, in this case) all at once, it's fine; however, if I try to read in two smaller batches (say, first time 6, and second time 7), the first read returns (with the 6 bytes), but the second read never returns.
As far as I know, this is not expected behaviour for SOCK_STREAM sockets. I tried looking into the problem so I instrumented net/unix/af_unix.c to see what is going on. More specifically, I was focusing on the function unix_stream_recvmsg. Here is what I noticed:
- there is a skb in the sk_receive_queue with a len of 13 - 6 bytes are read from it - a skb with the remaining 7 bytes is requeued in sk_receive_queue - on the next call to unix_stream_recvmsg, the sk_receive_queue is empty (!)
Thus, this confirms the behaviour observed from userspace. Is this a bug? Who could be removing the skb from the receive_queue?
Thanks for any ideas/suggestions,
Catalin
ps Please cc: your replies to me.
- 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/
| |