Comments on: select system call limitation in Linux

By: Nandhini

Nandhini — Mon, 11 Apr 2011 21:53:13 +0000

please give full example

By: Moises Silva

Moises Silva — Tue, 17 Aug 2010 14:58:08 +0000

That’s interesting to know Simal. Typical trade-off between memory and cpu usage.

By: Simal Haneef

Simal Haneef — Tue, 17 Aug 2010 10:19:20 +0000

// The maximum file descriptors per process supported on HP is 60000
#define FD_SETSIZE 60000

#ifdef LINUX_OS
# include
# undef __FD_SETSIZE
# define __FD_SETSIZE 60000
#include
#endif

This can be a generic code applying on all platforms .. you can have up to 60000 FDS … fd_set will be an array of size 60000

By: Moises Silva

Moises Silva — Wed, 23 Jun 2010 21:17:12 +0000

Nice to know. I thought may be the kernel could possibly cut off the size too, bu I went and quickly looked to how the kernel handles the fd set. It’s interesting to know that the kernel will allocate on the stack for small n values and then try with kmalloc if the stack memory is not enough for the user requested n value.

By: Jan Ringoš

Jan Ringoš — Mon, 21 Jun 2010 08:01:34 +0000

None of the FD_SET macros I have seen do any check against FD_SETSIZE. When using too small buffer for fd_set, the memory gets corrupted even before the call to “select”. So there is IMHO no point in checking against FD_SETSIZE in “select”. To be sure I looked at the sources and haven’t found anything that would suggest otherwise.

By: Moises Silva

Moises Silva — Fri, 14 May 2010 15:03:12 +0000

That’s an interesting approach. I thought at least libc recompilation with a different fd set size would be required.

By: Jan Ringoš

Jan Ringoš — Thu, 13 May 2010 07:59:20 +0000

The solution is simple. Take the highest file descriptor value, add 8, divide by 8, allocate that many bytes of memory, memset the block to zeros, and then use the memory instead of your fd_set.