您好,登錄后才能下訂單哦!
這篇文章將為大家詳細(xì)講解有關(guān)Linux系統(tǒng)下fd分配的方法是什么,文章內(nèi)容質(zhì)量較高,因此小編分享給大家做個(gè)參考,希望大家閱讀完這篇文章后對(duì)相關(guān)知識(shí)有一定的了解。
最近幾天在公司里寫網(wǎng)絡(luò)通訊的代碼比較多,自然就會(huì)涉及到IO事件監(jiān)測(cè)方法的問題。我驚奇的發(fā)現(xiàn)select輪訓(xùn)的方法在那里居然還大行其道。我告訴他們現(xiàn)在無論在Linux系統(tǒng)下,還是windows系統(tǒng)下,select都應(yīng)該被廢棄不用了,其原因是在兩個(gè)平臺(tái)上select的系統(tǒng)調(diào)用都有一個(gè)可以說是致命的坑。
在windows上面單個(gè)fd_set中容納的socket handle個(gè)數(shù)不能超過FD_SETSIZE(在win32 winsock2.h里其定義為64,以VS2010版本為準(zhǔn)),并且fd_set結(jié)構(gòu)使用一個(gè)數(shù)組來容納這些socket handle的,每次FD_SET宏都是向這個(gè)數(shù)組中放入一個(gè)socket handle,并且此過程中是限定了不能超過FD_SETSIZE,具體請(qǐng)自己查看winsock2.h中FD_SET宏的定義。
此處的問題是
若本身fd_set中的socket handle已經(jīng)達(dá)到FD_SETSIZE個(gè),那么后續(xù)的FD_SET操作實(shí)際上是沒有效果的,對(duì)應(yīng)socket handle的IO事件將被遺漏?。?!
而在Linux系統(tǒng)下面,該問題其實(shí)也是處在fd_set的結(jié)構(gòu)和FD_SET宏上。此時(shí)fd_set結(jié)構(gòu)是使用bit位序列來記錄每一個(gè)待檢測(cè)IO事件的fd。記錄的方式稍微復(fù)雜,如下
/usr/include/sys/select.h中
typedef long int __fd_mask; #define __NFDBITS (8 * sizeof (__fd_mask)) #define __FDELT(d) ((d) / __NFDBITS) #define __FDMASK(d) ((__fd_mask) 1 << ((d) % __NFDBITS)) typedef struct { /* XPG4.2 requires this member name. Otherwise avoid the name from the global namespace. */ #ifdef __USE_XOPEN __fd_mask fds_bits[__FD_SETSIZE / __NFDBITS]; # define __FDS_BITS(set) ((set)->fds_bits) #else __fd_mask __fds_bits[__FD_SETSIZE / __NFDBITS]; # define __FDS_BITS(set) ((set)->__fds_bits) #endif } fd_set; #define FD_SET(fd, fdsetp) __FD_SET (fd, fdsetp)
/usr/include/bits/select.h中
1 # define __FD_SET(d, set) (__FDS_BITS (set)[__FDELT (d)] |= __FDMASK (d))
可以看出,在上面的過程,實(shí)際上每個(gè)bit在fd_set的bit序列中的位置對(duì)應(yīng)于fd的值。而fd_set結(jié)構(gòu)中bit位個(gè)數(shù)是__FD_SETSIZE定義的,__FD_SETSIZE在/usr/include/bits/typesize.h(包含關(guān)系如下sys/socket.h -> bits/types.h -> bits/typesizes.h)中被定義為1024。
現(xiàn)在的問題是,當(dāng)fd>=1024時(shí),F(xiàn)D_SET宏實(shí)際上會(huì)引起內(nèi)存寫越界。而實(shí)際上在man select中對(duì)已也有明確的說明,如下
NOTES
An fd_set is a fixed size buffer. Executing FD_CLR() or FD_SET() with a value of fd that is negative or is equal to or
larger than FD_SETSIZE will result in undefined behavior. Moreover, POSIX requires fd to be a valid file descriptor.
這一點(diǎn)包括之前的我,是很多人沒有注意到的,并且云風(fēng)大神有篇博文《一起 select 引起的崩潰》也描述了這個(gè)問題。
可以看出在Linux系統(tǒng)select也是不安全的,若想使用,得小心翼翼的確認(rèn)fd是否達(dá)到1024,但這很難做到,不然還是老老實(shí)實(shí)的用poll或epoll吧。
扯得有點(diǎn)遠(yuǎn)了,但也引出了本片文章要敘述的主題,就是Linux系統(tǒng)下fd值是怎么分配確定,大家都知道fd是int類型,但其值是怎么增長(zhǎng)的,在下面的內(nèi)容中我對(duì)此進(jìn)行了一點(diǎn)分析,以2.6.30版本的kernel為例,歡迎拍磚。
首先得知道是哪個(gè)函數(shù)進(jìn)行fd分配,對(duì)此我以pipe為例,它是分配fd的一個(gè)典型的syscall,在fs/pipe.c中定義了pipe和pipe2的syscall實(shí)現(xiàn),如下
SYSCALL_DEFINE2(pipe2, int __user *, fildes, int, flags) { int fd[2]; int error; error = do_pipe_flags(fd, flags); if (!error) { if (copy_to_user(fildes, fd, sizeof(fd))) { sys_close(fd[0]); sys_close(fd[1]); error = -EFAULT; } } return error; } SYSCALL_DEFINE1(pipe, int __user *, fildes) { return sys_pipe2(fildes, 0); }
進(jìn)一步分析do_pipe_flags()實(shí)現(xiàn),發(fā)現(xiàn)其使用get_unused_fd_flags(flags)來分配fd的,它是一個(gè)宏
#define get_unused_fd_flags(flags) alloc_fd(0, (flags)),位于include/linux/fs.h中
好了咱們找到了主角了,就是alloc_fd(),它就是內(nèi)核章實(shí)際執(zhí)行fd分配的函數(shù)。其位于fs/file.c,實(shí)現(xiàn)也很簡(jiǎn)單,如下
int alloc_fd(unsigned start, unsigned flags) { struct files_struct *files = current->files; unsigned int fd; int error; struct fdtable *fdt; spin_lock(&files->file_lock); repeat: fdt = files_fdtable(files); fd = start; if (fd < files->next_fd) fd = files->next_fd; if (fd < fdt->max_fds) fd = find_next_zero_bit(fdt->open_fds->fds_bits, fdt->max_fds, fd); error = expand_files(files, fd); if (error < 0) goto out; /* * If we needed to expand the fs array we * might have blocked - try again. */ if (error) goto repeat; if (start <= files->next_fd) files->next_fd = fd + 1; FD_SET(fd, fdt->open_fds); if (flags & O_CLOEXEC) FD_SET(fd, fdt->close_on_exec); else FD_CLR(fd, fdt->close_on_exec); error = fd; #if 1 /* Sanity check */ if (rcu_dereference(fdt->fd[fd]) != NULL) { printk(KERN_WARNING "alloc_fd: slot %d not NULL!\n", fd); rcu_assign_pointer(fdt->fd[fd], NULL); } #endif out: spin_unlock(&files->file_lock); return error; }
在pipe的系統(tǒng)調(diào)用中start值始終為0,而中間比較關(guān)鍵的expand_files()函數(shù)是根據(jù)所給的fd值,判斷是否需要對(duì)進(jìn)程的打開文件表進(jìn)行擴(kuò)容,其函數(shù)頭注釋如下
/* * Expand files. * This function will expand the file structures, if the requested size exceeds * the current capacity and there is room for expansion. * Return <0 error code on error; 0 when nothing done; 1 when files were * expanded and execution may have blocked. * The files->file_lock should be held on entry, and will be held on exit. */
此處對(duì)其實(shí)現(xiàn)就不做深究了,回到alloc_fd(),現(xiàn)在可以看出,其分配fd的原則是
每次優(yōu)先分配fd值最小的空閑fd,當(dāng)分配不成功,即返回EMFILE的錯(cuò)誤碼,這表示當(dāng)前進(jìn)程中fd太多。
到此也印證了在公司寫的服務(wù)端程序(kernel是2.6.18)中,每次打印client鏈接對(duì)應(yīng)的fd值得變化規(guī)律了,假如給一個(gè)新連接分配的fd值為8,那么其關(guān)閉之后,緊接著的新的鏈接分配到的fd也是8,再新的鏈接的fd值是逐漸加1的。
為此,我繼續(xù)找了一下socket對(duì)應(yīng)fd分配方法,發(fā)現(xiàn)最終也是 alloc_fd(0, (flags),調(diào)用序列如下
socket(sys_call) -> sock_map_fd() -> sock_alloc_fd() -> get_unused_fd_flags()
open系統(tǒng)調(diào)用也是用get_unused_fd_flags(),這里就不列舉了。
現(xiàn)在想回頭說說開篇的select的問題。由于Linux系統(tǒng)fd的分配規(guī)則,實(shí)際上是已經(jīng)保證每次的fd值盡量的小,一般非IO頻繁的系統(tǒng),的確一個(gè)進(jìn)程中fd值達(dá)到1024的概率比較小。因而對(duì)此到底是否該棄用select,還不能完全地做絕對(duì)的結(jié)論。如果設(shè)計(jì)的系統(tǒng)的確有其他措施保證fd值小于1024,那么用select無可厚非。
但在網(wǎng)絡(luò)通訊程序這種場(chǎng)合是絕不應(yīng)該作此假設(shè)的,所以還是盡量的不用select吧??!
關(guān)于Linux系統(tǒng)下fd分配的方法是什么就分享到這里了,希望以上內(nèi)容可以對(duì)大家有一定的幫助,可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò),可以把它分享出去讓更多的人看到。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。