On Mon, 23 Apr 2001 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. This advice is true in one half and irritating in a second half. I can imagine a situation, where the array is an appropriate means. Lee Chin probably uses select(). Hashes are good, but when the system CAN cater programmers needs without any drawbacks (i think this is the case - in case of PID's they should increase, but here is no reason), it should. Who would give extra time to debug and test hashes for effectivity... I think you just should use dup2() and close(the old fd) - you can select the fd by yourself! So maybe you won't need an array at all (neither hash). > If you don't want my peaches, then don't shake my tree. I didn't, they fell by themselves to my mailbox :-) Tomas - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org
