Re: [MiNT] Ammount of file descriptors per process

[Frank Naumann <fnaumann@cs.uni-magdeburg.de>]

Hello!

> 2. Opening files using library call open(), the maximum ammount of files it 
> tries to open is taken from RLIMIT_NOFILE library constant.

This is not a constant, this is a dynamic per process resource limit. And 
this number don't represent the number of descriptors a process can open:

RLIMIT_NOFILE

    This is a number one greater than the maximum value that the system
    may assign to a newly-created descriptor. If this limit is exceeded,
    functions that allocate new file descriptors may fail with errno set
    to [EMFILE]. This limit constrains the number of file descriptors
    that a process may allocate.

> 3. Opening (creating) files using system call Fcreate(), the maximum ammount 
> of files it tries to open is taken from Sysconf(SYS_MAXFILES) system call.

 * Sysconf(which): returns information about system configuration.
 *       2      max. number of open files per process   {OPEN_MAX}

> Ad 3. Sysconf(SYS_MAXFILES) returns 32. Test fails after opening 26 files.

This is not the number of files you can open, this is the maximum number 
of files a process can have open. Under Unix every process have at least 3 
open file descriptors at start (stdin, stdout, stderr). Under FreeMiNT 
it's more due to TOS emulation.

> Conclusions:
>
> At the beginning _process_that_does_nothing_ has 9 file descriptors opened 
> (according to /kerm/*/fd). If 32 is a maximum ammount of file descriptors per 
> process, then 26 + 9 = 35, so there is something wrong here.
>
> On the other hand FOPEN_MAX is wrong, and can lead to hard to trace errors in 
> ported software.
>
>
> Or, if I'm wrong please correct me.

Except the FOPEN_MAX constant I don't see any problem or violation of the 
standards.


Regards,
Frank

--
ATARI FALCON 060 // MILAN 060
-----------------------------------------
http://www.cs.uni-magdeburg.de/~fnaumann/
e-Mail: fnaumann@freemint.de