On Sun, Apr 22, 2001 at 11:26:59PM -0400, 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);
Quaint... I use just close(fd) for that.
Do you mean the fd STAYS behind if you do that ?
(As shown by the /proc/XXX/fd/ pseudo-directory ?)
If it does, it may be indicative of some bug in the system.
Which kernel version you are running ? What architecture ?
> 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).
It won't increase beyond the limit of:
getrlimit(RLIMIT_NOFILE, &rlimits)
(See "man getrlimit")
> I have two problems:
> 1) I'm using the file descriptor as an index into a fixed size array
Make sure its size is at least your number-of-files limit.
> 2) I'm scared of eventually running out of file descriptors.
In general you will sooner or latter encounter a situation
where you will run out of file descriptors -- it all depends
just on the lifetimes of the connections. Prepare for it.
If the average lifetime exceeds the average in between birth-
events (accept()s), your population (number of fds) will increase.
> Further more, when I do a "file /proc/PID/fd/XXX" I get a "/proc/PID/fd/XXX:
> broken symbolic link to socket:[BLAH]"
>
> Why is this file descriptor still lingering around and how do I get rid of
> it when I do a close on the socket?
Is it really lingering ?
Like I said in the beginning, it may be a kernel bug, in which
case we need to know which kernel version you are using.
> Thanks
> Lee
/Matti Aarnio
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.linux-learn.org/faqs