Re: User-settable FD_SETSIZE and select()

[mtk-lists at gmx dot net]

[This is a possble duplicate, since I think I failed to include the 
list on an earlier send of this message]

> On Tue, May 20, mtk-lists@gmx.net wrote:
> 
> > > Use poll().  
> > 
> > This does make it harder to port applications using select() from other 
> > implementations which allow higher limits for FD_SETSIZE.  E.g., HP/UX
> > has a limit of 2048, and Tru64 has 4096.  And while the default limit os
> > 1024 on Solaris, I seem to recall it can be raised.
> > 
> > > FD_SETSIZE will not be changed,  it's not binary compatible.
> > 
> > I'm not sure what you are meaning here -- "not binary compatible" with
what?
> 
> With existing binaries.
> 
> > As I noted, manually editing the current glibc header files allows
anapplication
> > to use higher FD_SETSIZE values without the need for either a Linux
kernel
> > rebuild or a glibc rebuild.
> 
> Change FD_SETSIZE, recompile glibc or an application using RPC
> and use excessive RPC applications and portmap. You will get a lot
> of mysterious errors.

Hello Thorsten,

Thanks for your note.  Maybe I'm being slow.  What is to stop one 
having something like:

#ifndef FD_SETSIZE 
#define FD_SETSIZE __FD_SETSIZE
#endif

(or some such, I assume you get the drift), so that applications 
that want it can do a "cc -DFD_SETSIZE=n".  This doesn't require 
a glibc recompilation, and should therefore not effect the RPC stuff 
(since it doesn't attempt to redefine FD_SETSIZE).  Or am I 
missing something still?  

Really, all I'm looking for is a simple way of changing the idea that 
FD_ZERO() has of the size of an fd_set.  (FD_ZERO is the only one 
of the FD_*() macros that depends on size of an fd_set.) As I said, 
the Linux kernel already handles larger set sizes (it derives its info 
from the first argument of select()).

Cheers,

Michael

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!