open_file_cache with NGX_HAVE_PREAD 0

[Joel Cunningham]

I'm running NGINX on a Unix like embedded platform that doesn't have pread() implemented, so I have NGX_HAVE_PREAD set to 0 and am using the Unix version of ngx_files.c

I've been testing out the open file cache and I've found what seems to be an incompatibility with systems not supporting pread.

The sys_offset (from ngx_file_t) used in the non-pread case isn't cached in the open file cache. When a module opens the cached file, the sys_offset in its ngx_file_t starts out at 0 instead of the current position of the file. This causes issues when the file is not actually at position 0, but both sys_offset and offset are at 0 (thus we don't seek).

Additionally, if two HTTP requests for the same file happen simultaneously, each will have its own sys_offset and won't be updated when the other request moves the file position.

Is the NGX_HAVE_PREAD 0 configuration not used on any POSIX systems now-a-days and is dead code?

One fix that I could think of is to just seek every time since we can't rely on sys_offset in these configurations.

If we want to avoid the seek and to fix the multiple requests case, we would need to update a single copy of sys_offset, which I don't believe there is infrastructure in place for that.

[Maxim Dounin]

While nginx is able to work on systems without pread(), for the mentioned reasons open_file_cache cannot be used on such systems. Trying to fix this unlikely worth the effort - given that pread() is present almost everywhere now, open_file_cache effect is minimal, and additional seeks are likely to make this effect even smaller if not negative.

[Joel Cunningham]

It would be nice if we could flag a configuration error if NGX_HAVE_PREAD is 0 and open file cache are used together. Maybe a check (surrounded by #if !NGX_HAVE_PREAD) in ngx_http_core_open_file_cache() if the directive is set to "on"?

This way any users with NGX_HAVE_PREAD 0 would at least not have to debug the code to figure out the limitation