作者：[email protected]
博客：blog.focus-linux.net linuxfocus.blog.chinaunix.net
博客：blog.focus-linux.net linuxfocus.blog.chinaunix.net
本文的copyleft歸[email protected]所有，使用GPL發佈，可以自由拷貝，轉載。但轉載請保持文檔的完整性，註明原作者及原鏈接，嚴禁用於任何商業用途。
======================================================================================================
今天探討一個很看似簡單的API “read”的返回值問題。read的返回值有哪幾個值？每個值又是在什麼情況下發生的？
先問一下男人吧：man 2 read
RETURN VALUE
On success, the number of bytes read is returned (zero indicates end of file), and the file position is advanced by this number. It is not an error if this number is smaller than the number of bytes requested; this
may happen for example because fewer bytes are actually available right now (maybe because we were close to end-of-file, or because we are reading from a pipe, or from a terminal), or because read() was interrupted by a signal. On error, -1 is returned,
and errno is set appropriately. In this case it is left unspecified whether the file position (if any) changes.
從上面的描述中，read的返回值一共有三種情況：
1. 大於0：成功讀取的字節數；
2. 等於0：到達文件尾；
3. -1：發生錯誤，通過errno確定具體錯誤值。
Note：本次討論只限於阻塞的fd，不討論非阻塞的情況。
通過這個man的介紹，看似read的應用很簡單，但真的是這樣嗎？莫忘了Linux中文件是一個很common的概念。它可以是一個真實的文件，也可以是一個socket，一個設備，等等。對於真實的文件，文件尾EOF是一個確定的情況。
那麼如果是一個socket，它的返回值何時爲0呢？還有，在read的過程中，如果被信號中斷，究竟是返回-1，還是返回一個正值或者0呢？當對端關閉後，是否socket還可以讀取對端關閉socket前發送的數據呢？
爲了搞清楚socket的行爲，必須要研究一下對應的kernel的代碼。本次以unix域的TCP連接的socket爲例，來探討一下socket的行爲。
unix_stream_recvmsg爲unix域的TCP連接的socket的讀取函數：
-
static int unix_stream_recvmsg(struct kiocb *iocb, struct
socket *sock,
-
struct msghdr *msg, size_t size,
-
int flags)
-
{
-
struct sock_iocb *siocb = kiocb_to_siocb(iocb);
-
struct scm_cookie tmp_scm;
-
struct sock *sk = sock->sk;
-
struct unix_sock *u = unix_sk(sk);
-
struct sockaddr_un *sunaddr = msg->msg_name;
-
int copied = 0;
-
int check_creds = 0;
-
int target;
-
int err = 0;
-
long timeo;
-
-
err = -EINVAL;
-
if (sk->sk_state != TCP_ESTABLISHED)
-
goto out;
-
-
err = -EOPNOTSUPP;
-
if (flags&MSG_OOB)
-
goto out;
-
-
target = sock_rcvlowat(sk, flags&MSG_WAITALL, size);
-
timeo = sock_rcvtimeo(sk, flags&MSG_DONTWAIT);
-
-
msg->msg_namelen = 0;
-
-
/* Lock the socket to prevent queue disordering
-
* while sleeps in memcpy_tomsg
-
*/
-
-
if (!siocb->scm) {
-
siocb->scm = &tmp_scm;
-
memset(&tmp_scm, 0, sizeof(tmp_scm));
-
}
-
-
mutex_lock(&u->readlock);
-
-
do {
-
int chunk;
-
struct sk_buff *skb;
-
-
unix_state_lock(sk);
-
skb = skb_dequeue(&sk->sk_receive_queue);
-
if (skb == NULL) {
-
if (copied >= target)
-
goto unlock;
-
-
/*
-
* POSIX 1003.1g mandates this order.
-
*/
-
-
err = sock_error(sk);
-
if (err)
-
goto unlock;
-
if (sk->sk_shutdown & RCV_SHUTDOWN)
-
goto unlock;
-
-
unix_state_unlock(sk);
-
err = -EAGAIN;
-
if (!timeo)
-
break;
-
mutex_unlock(&u->readlock);
-
-
timeo = unix_stream_data_wait(sk, timeo);
-
-
if (signal_pending(current)) {
-
err = sock_intr_errno(timeo);
-
goto out;
-
}
-
mutex_lock(&u->readlock);
-
continue;
-
unlock:
-
unix_state_unlock(sk);
-
break;
-
}
-
unix_state_unlock(sk);
-
-
if (check_creds) {
-
/* Never glue messages from different writers */
-
if ((UNIXCB(skb).pid != siocb->scm->pid) ||
-
(UNIXCB(skb).cred != siocb->scm->cred)) {
-
skb_queue_head(&sk->sk_receive_queue, skb);
-
break;
-
}
-
} else {
-
/* Copy credentials */
-
scm_set_cred(siocb->scm, UNIXCB(skb).pid, UNIXCB(skb).cred);
-
check_creds = 1;
-
}
-
-
/* Copy address just once */
-
if (sunaddr) {
-
unix_copy_addr(msg, skb->sk);
-
sunaddr = NULL;
-
}
-
-
chunk = min_t(unsigned int, skb->len, size);
-
if (memcpy_toiovec(msg->msg_iov, skb->data, chunk)) {
-
skb_queue_head(&sk->sk_receive_queue, skb);
-
if (copied == 0)
-
copied = -EFAULT;
-
break;
-
}
-
copied += chunk;
-
size -= chunk;
-
-
/* Mark read part of skb as used */
-
if (!(flags & MSG_PEEK)) {
-
skb_pull(skb, chunk);
-
-
if (UNIXCB(skb).fp)
-
unix_detach_fds(siocb->scm, skb);
-
-
/* put the skb back if we didn't
use it up.. */
-
if (skb->len) {
-
skb_queue_head(&sk->sk_receive_queue, skb);
-
break;
-
}
-
-
consume_skb(skb);
-
-
if (siocb->scm->fp)
-
break;
-
} else {
-
/* It is questionable, see
note in unix_dgram_recvmsg.
-
*/
-
if (UNIXCB(skb).fp)
-
siocb->scm->fp = scm_fp_dup(UNIXCB(skb).fp);
-
-
/* put message back and return */
-
skb_queue_head(&sk->sk_receive_queue, skb);
-
break;
-
}
-
} while (size);
-
-
mutex_unlock(&u->readlock);
-
scm_recv(sock, msg, siocb->scm, flags);
-
out:
-
return copied ? : err;
- }
在這個函數中只有一個出口：
- return copied ? : err;
copied在unix_stream_recvmsg爲已讀取的字節數。那麼這行代碼的意義就比較明顯了，當已讀取了一定數據，那麼read的返回值即爲讀取的字節數。當沒有讀取任何數據時，就返回err。
下面看前面提出的兩個問題：
1. 何時返回值爲0；
2. 被信號中斷時，read的返回值是什麼？
3. 對端關閉後，是否可以繼續讀取對端關閉前發送的數據呢？
先看第一個問題：何時返回值爲0。這需要copied爲0，且err爲0。
-
err = sock_error(sk);
-
if (err)
-
goto unlock;
-
if (sk->sk_shutdown & RCV_SHUTDOWN)
- goto unlock;
這幾行代碼告訴了我們答案。首先這幾行代碼是在socket的receive queue沒有數據時，纔會運行到達的。當socket沒有錯誤時，會繼續堅持socket的RCV_SHUTDOWN標誌位，如果設置了該標誌位，則goto 到unlock，直至最後的return返回語句。此時，copied爲0時，err也會爲0.
而sk->sk_shutdown的標誌位會在兩種情況下被設置，參見unix_shutdown函數。在unix_shutdown函數，由API close或者shutdown觸發，它不僅設置了本端的sk_shutdown標誌位，還會設置對端相對應的sk_shutdown標誌位。所以無論是本端還是對端調用shutdown或者close時，都有可能導致本端的read返回爲0。這裏之所以說可能導致，是因爲shutdown時可以指定shutdown的行爲，是關閉發送還是接收。
第二個問題，被信號中斷時，返回值是什麼？
-
timeo = unix_stream_data_wait(sk, timeo);
-
-
if (signal_pending(current)) {
-
err = sock_intr_errno(timeo);
-
goto out;
- }
這幾行代碼是這個問題的答案。這幾行代碼同樣是處於receive queue爲空的判斷中。那麼，這說明如果receive queue中已有數據，且大於要讀取的字節數，那麼在這個函數中，根本就不會去判斷是否有pending的信號，返回值爲讀取的字節數。如果receive
queue中沒有足夠的數據，那麼就會運行到此處，檢查是否有pending的信號。當有信號pending時，這時的返回值就決定於copied的值。如果已讀取了一些字節，那麼就返回copied即已讀取了的字節數——小於我們要去讀取的字節數。如果沒有讀取任何字節，那麼就返回-1，且errno爲EINTR。
第三個問題，對端關閉後，是否可以讀取對端在關閉之前發送的數據。
從前面兩個問題以及第一個問題的答案。這個問題的答案也很明顯了。在unix_stream_recvmsg中，只要receive queue中有數據，那麼就不會去檢查是否sk_shutdown的標誌。所以答案是，即使對端關閉socket，本端仍可以讀取對端在關閉之前發送的數據。
本文只探討了unix域的TCP連接的socket的讀取情況。至於其它種類的socket的read行爲，我猜測Linux仍然會採取一致的行爲——有心人可以去看代碼驗證一下。
