Am Montag, 23. April 2001 08:50 schrieb Glynn Clements:
> lawson_whitney@juno.com wrote:
> > > 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,
>
> Are you quite sure about that? I'm quite sure that accept() exhibits
> the same behaviour as open(), dup() etc, i.e. it always returns the
> lowest-numbered unused descriptor. I'm not aware of any system call
> which allocates descriptors but doesn't behave this way.
>
> > 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.
>
> Unnecessary; a descriptor is an "int", but that doesn't mean it can be
> *any* int. IIRC, you won't see a value >= 1024 unless you've modified
> your kernel source.
>
> > 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,
>
> Er, are you under the impression that file descriptors are *arbitrary*
> integers? They aren't; they are "small", non-negative integers
> ("small" meaning that you can reasonably use them as an array index).
>
> > and what you get is an "OS" like win31 or win9x. Hash them instead.
>
> Quite the opposite; Unlike Unix, Windows *does* use arbitrary integer
> "handles" for this type of thing (one of the many reasons why WinSock
> only superficially resembles BSD sockets).
>
I want to add: using the FD as an index into an array is common practise
in writing resource managers in QNX4 and QNX Neutrino. And BTW,
the FD is directly mapped to the channel ID (a concept borrowed
from plan9). No need for hash tables -> save some cpu cycles!
Using the FDs in this way is OK on systems that behaves like Unix, i.e.
returning the lowest unused FD number for this process.
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
