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.
--- [EMAIL PROTECTED] 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.
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-net" in
> the body of a message to [EMAIL PROTECTED]
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
-
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
