if there's no crash, how would we know if 4096 is not enough for our tasks?
I.e., if your guest apps work fine when they open too many files from Shared Folders, then it is enough. But if your guest apps report some kind of errors when open files from Shared Folders, then you have to increase the limit. The crashes is another story.
I'll try to clarify. There is a limit on maximum number of simultaneously open files for every process in OSX and the process may adjust this limit for itself. In Parallels Desktop the maximum number of files that can be open simultaneously by a guest application from Parallels Shared Folders (\\Mac\<folder>) also bound by this limit (that is set in prl_vm_app process). Some guest apps in particular workloads open too many files from Parallels Shared Folders, reach the limit and start failing. I.e., if we want our guest apps to work fine, we have to increase the limit in prl_vm_app process. There is a default limit we set on startup of prl_vm_app and there is a mechanism to adjust this default by the environment variable we mentioned before. So.
1) Before PD11 we didn't set the limit and were bound by the OSX default 10k. We sometimes crashed when the count of open files reached 1024. The crash is the FD_SET() problem (it is illegal to call FD_SET() with an FD value higher than 1024).
2) In 11.0.0-11.0.1 our default limit was 512. This fixed the crashes (since we now didn't have 1024+ FDs), but also affected guest apps that open too many files. Increasing to 1024 might be a sufficient relax for some of the apps. Increasing to higher than 1024 still unsafe due to the crashes.
3) In 11.0.2 the crash is fixed (possibility of calling FD_SET() with 1024+ FDs had been eliminated) and the default increased from 512 to 4096. That's all we've done.
