Have a look at the getdtablesize() function in libc, and use that to set the FD_SETSIZE constant, since that will always return the *actual* open file limit for the process.

As to why you get segfaults with your new definition, is due to what FDSet (aka fd_set in C) is supposed to represent.  Its a bitset that has a bit representing each file descriptor that select(3) is supposed to monitor.  Your new definition has only enough space for 32 file descriptors (on a 32bit system), so when you perform an operation that tries to read/write file descriptor 32 or above in that bitset, it will segfault.

On Friday, 9 November 2012 05:45:58 UTC+10, Hans Hasselberg wrote:

Hello!

Thank you very much for this library!

I stumbled over a problem with code I 'inherited', it is a gem which wraps libcurl.

This code works, but consumes too much memory for my taste and looks suspicious!

https://github.com/typhoeus/ethon/blob/master/lib/ethon/curls/classes.rb:

class FDSet < FFI::Struct

  FD_SETSIZE = 524288

  layout :fds_bits, [:long, FD_SETSIZE / FFI::Type::LONG.size]

end

I can change that code to:

class FDSet < FFI::Struct

  layout :fds_bits, :long

end

Instances of FDSet do not consume so much memory any more, but I get segfaults on a regular basis. It seems to me, that fds_bits is just a memory placeholder.

The ffi code in that particular project looks quite understandable except for that FDSet. 

Could you explain to me, why my code segfaults with the changed code and if FDSet is correct specified? I bet you need more information, but I don't know which, so feel free to ask!

Cheers,

Hans