probably there is a solution like, when u get a fd then just call "dup" on that fd and get the newfd. now close the old fd and use this newfd to index into the array and do your job. dup guarantees that the fd which will be returned will be the lowed numbered one which is closed in the file descp. table of your process. So, if u are having a max bound on the number of fd's which the process will be using then u can easily do the job by having a max. sized array (i.e. the one having a size fo max number of fd which u can open). hope it solves your problem... PS: see "man dup" for further details. --- lawson_whitney@juno.com wrote: > > > On Sun, 22 Apr 2001, Lee Chin wrote: > > > This is more of a Linux socket API question... I > have a server thread that > > accepts (accept sys call) socket connections and > then services a client > > request and closes the socket connection using: > > > > shutdown(fd, SHUT_RDWR); > > close(fd); > > > > My problem is this... after a while I see that the > file descriptor returned > > by the accept system call slowly starts > increasing. It starts increasing in > > the integer file descriptor number returned by the > system call (the FD that > > we use to do the read and write system calls). > > > > I have two problems: > > 1) I'm using the file descriptor as an index into > a fixed size array > > Don't. You don't control the value of the fd, so it > is unwise to use it > as an index unless your array can have as many > entries as the type of > the index can have values. That is a lot of core to > hold not much > content, and even if it is only virtual. it has to > be mapped to > somewhere. If they have to cater for programmers > like you, programmers > like you give OS programmers hives, and what you get > is an "OS" like > win31 or win9x. Hash them instead. > > > 2) I'm scared of eventually running out of file > descriptors. > > I don't think you will. When it gets around to > them, I think the system > will reuse the old numbers, but I can't see an easy > way to force it to. > > > > Further more, when I do a "file /proc/PID/fd/XXX" > I get a "/proc/PID/fd/XXX: > > broken symbolic link to socket:[BLAH]" > > > You'll have to be a bit more specific what you mean > by XXX before I can > answer that. Maybe not. broken symbolic link means > socket:[BLAH] is > gone. Doesn't exist. You closed it, you don't love > it anymore, it has > walked out on you. GONE. > > > Why is this file descriptor still lingering around > and how do I get rid of > > it when I do a close on the socket? > > It isn't. Just hash the damned fd's. > > > > Thanks > > Lee > > Lawson > > If you don't want my peaches, then don't shake my > tree. > ---cut here > > > ________________________________________________________________ > GET INTERNET ACCESS FROM JUNO! > Juno offers FREE or PREMIUM Internet access for > less! > Join Juno today! For your FREE software, visit: > http://dl.www.juno.com/get/tagj. > - > : send the line > "unsubscribe linux-net" in > the body of a message to majordomo@vger.kernel.org __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org
