Increase file descriptor limit in NativeAOT app process

[akoeplinger]

CoreCLR and soon Mono (after https://github.com/dotnet/runtime/pull/82429) call a function that will increase the maximum open file descriptors via a function like this, should NativeAOT do the same? https://github.com/dotnet/runtime/blob/2bdc3cb8dd3500aa2b3a51b558782560b26b5973/src/coreclr/pal/src/init/pal.cpp#L1087-L1093

/cc @dotnet/ilc-contrib

[ghost]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas See info in area-owners.md if you want to be subscribed.

Issue Details

---

Both CoreCLR and Mono call a function that will increase the maximum open file descriptors via a function like this, should NativeAOT do the same? https://github.com/dotnet/runtime/blob/2bdc3cb8dd3500aa2b3a51b558782560b26b5973/src/coreclr/pal/src/init/pal.cpp#L1087-L1093 /cc @dotnet/ilc-contrib

Author:	akoeplinger
Assignees:	-
Labels:	`area-NativeAOT-coreclr`
Milestone:	-

[VSadov]

It probably makes sense, just for parity purposes. I am curious - are there specific reasons for this in CoreCLR/Mono or is it "just in case"? Any interesting history for why the call was introduced?

[jkotas]

FWIW, this is disabled on Alpine and nobody ever complained about it there: https://github.com/dotnet/runtime/blob/e9b9489f41cface8f537f87ab1e187c9244c5ea9/src/coreclr/pal/src/CMakeLists.txt#L95-L96

[akoeplinger]

I don't know about the historical context (the function was already part of the initial CoreCLR github commit) but we recently saw issues if this isn't done during NuGet restore: https://github.com/dotnet/runtime/issues/82428

[jkotas]

historical context

This was part of the original Rotor PAL: https://github.com/SSCLI/sscli_20021101/blob/77d46e0f04f52052a12ac40ce2cf96712c934b3c/pal/unix/init/pal.c#L629 .

[VSadov]

I remember there was a bug fix for when we could temporarily have too many fd's. I'll try finding details.

[VSadov]

Maybe it was to compensate for https://github.com/dotnet/runtime/issues/47859 ? (Assembly.Load opens /dev/zero in linux and does not close it)

It was fixed in https://github.com/dotnet/runtime/pull/48140

[VSadov]

At the time of Rotor using /dev/zero for anonymous memory mapping was likely the "right" way.

[akoeplinger]

Given we're seeing https://github.com/dotnet/runtime/issues/82428 when the limit is not increased I think it still makes sense to have it, though you could argue that with NativeAOT in library mode maybe the embedding application should have the final say.

[VSadov]

The scenario with NuGet looks real. The app has a scenario that may open 1K+ files and gets away with that on CorCLR, making this a compat issue.

I think we should increase the limit on NativeAOT and perhaps on Alpine too, unless the reason (debugging is broken) is still there.

[VSadov]

NativeAOT in library mode maybe the embedding application should have the final say.

No compat concerns in this case. It might be strange if library does this, especially if dynamically loaded.

[agocke]

It seems reasonable to match the CoreCLR behavior here.