filetable size being exceeded

[russellallen]

Self maintains a vector of size 256 called fileTable.

This is initialised to contain waiting semaphores in scheduler start. Incoming signals are mapped to this vector to handle file io. However in some circumstances (on FreeBSD) I'm seeing numbers > 255, even when I don't expect to have more than 256 files open.

Why?

See also scheduler signalToFile: fileNo

[kyle-github]

By default, a process on Linux can have 1024 open file handles. I assume that *BSD is not that much different. Every open socket, pipe and file takes one of those. That may include things like opening dynamic library files etc. Maybe old SunOS/Solaris had a limit of 255?

File descriptor handles are integers and there is nothing saying that they have to stay below 2^31. As far as I know, you are not given any guarantees about the value of a file descriptor handle other than it will be not be negative if the open operation is successful.

Signals themselves are integer values (raise() and kill()) as well. As far as I know there are no guarantees about those values. I am not even sure that they cannot be negative.

In my own C code, when using handles, I increment until INT_MAX and then wrap just to make ABA problems less likely.

Maybe use a sorted vector or a dictionary instead? Nearly all IO is on the order of microseconds or milliseconds so the search/lookup time is almost always lost in the noise.

[kyle-github]

MacOS has a limit of 256. I just checked. That could be the cause of the limit.

[russellallen]

SunOS/Solaris does seems to have had a 256 limit at the relevant time.

I'll try replacing the vector with a dictionary. As you say the lookup time shouldn't be an issue.

It is a bit tricky to muck around with in a live image!