* [PATCH] Cygwin: getdtablesize: always return OPEN_MAX_MAX @ 2021-01-28 2:51 Ken Brown 2021-01-28 10:20 ` Corinna Vinschen 0 siblings, 1 reply; 11+ messages in thread From: Ken Brown @ 2021-01-28 2:51 UTC (permalink / raw) To: cygwin-patches According to the Linux man page for getdtablesize(3), the latter is supposed to return "the maximum number of files a process can have open, one more than the largest possible value for a file descriptor." The constant OPEN_MAX_MAX is the only limit enforced by Cygwin, so we now return that. Previously getdtablesize returned the current size of cygheap->fdtab, Cygwin's internal file descriptor table. But this is a dynamically growing table, and its current size does not reflect an actual limit on the number of open files. With this change, gnulib now reports that getdtablesize and fcntl(F_DUPFD) work on Cygwin. Packages like GNU tar that use the corresponding gnulib modules will no longer use gnulib replacements on Cygwin. --- winsup/cygwin/syscalls.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc index 5da05b18a..1f16d54b9 100644 --- a/winsup/cygwin/syscalls.cc +++ b/winsup/cygwin/syscalls.cc @@ -2887,7 +2887,7 @@ setdtablesize (int size) extern "C" int getdtablesize () { - return cygheap->fdtab.size; + return OPEN_MAX_MAX; } extern "C" int -- 2.30.0 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] Cygwin: getdtablesize: always return OPEN_MAX_MAX 2021-01-28 2:51 [PATCH] Cygwin: getdtablesize: always return OPEN_MAX_MAX Ken Brown @ 2021-01-28 10:20 ` Corinna Vinschen 2021-01-28 13:42 ` Ken Brown 0 siblings, 1 reply; 11+ messages in thread From: Corinna Vinschen @ 2021-01-28 10:20 UTC (permalink / raw) To: cygwin-patches On Jan 27 21:51, Ken Brown via Cygwin-patches wrote: > According to the Linux man page for getdtablesize(3), the latter is > supposed to return "the maximum number of files a process can have > open, one more than the largest possible value for a file descriptor." > The constant OPEN_MAX_MAX is the only limit enforced by Cygwin, so we > now return that. > > Previously getdtablesize returned the current size of cygheap->fdtab, > Cygwin's internal file descriptor table. But this is a dynamically > growing table, and its current size does not reflect an actual limit > on the number of open files. > > With this change, gnulib now reports that getdtablesize and > fcntl(F_DUPFD) work on Cygwin. Packages like GNU tar that use the > corresponding gnulib modules will no longer use gnulib replacements on > Cygwin. > --- > winsup/cygwin/syscalls.cc | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc > index 5da05b18a..1f16d54b9 100644 > --- a/winsup/cygwin/syscalls.cc > +++ b/winsup/cygwin/syscalls.cc > @@ -2887,7 +2887,7 @@ setdtablesize (int size) > extern "C" int > getdtablesize () > { > - return cygheap->fdtab.size; > + return OPEN_MAX_MAX; > } getdtablesize is used internally, too. After this change, the values returned by sysconf and getrlimit should be revisited as well. Thanks, Corinna ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] Cygwin: getdtablesize: always return OPEN_MAX_MAX 2021-01-28 10:20 ` Corinna Vinschen @ 2021-01-28 13:42 ` Ken Brown 2021-01-28 16:07 ` Corinna Vinschen 0 siblings, 1 reply; 11+ messages in thread From: Ken Brown @ 2021-01-28 13:42 UTC (permalink / raw) To: cygwin-patches On 1/28/2021 5:20 AM, Corinna Vinschen via Cygwin-patches wrote: > On Jan 27 21:51, Ken Brown via Cygwin-patches wrote: >> According to the Linux man page for getdtablesize(3), the latter is >> supposed to return "the maximum number of files a process can have >> open, one more than the largest possible value for a file descriptor." >> The constant OPEN_MAX_MAX is the only limit enforced by Cygwin, so we >> now return that. >> >> Previously getdtablesize returned the current size of cygheap->fdtab, >> Cygwin's internal file descriptor table. But this is a dynamically >> growing table, and its current size does not reflect an actual limit >> on the number of open files. >> >> With this change, gnulib now reports that getdtablesize and >> fcntl(F_DUPFD) work on Cygwin. Packages like GNU tar that use the >> corresponding gnulib modules will no longer use gnulib replacements on >> Cygwin. >> --- >> winsup/cygwin/syscalls.cc | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc >> index 5da05b18a..1f16d54b9 100644 >> --- a/winsup/cygwin/syscalls.cc >> +++ b/winsup/cygwin/syscalls.cc >> @@ -2887,7 +2887,7 @@ setdtablesize (int size) >> extern "C" int >> getdtablesize () >> { >> - return cygheap->fdtab.size; >> + return OPEN_MAX_MAX; >> } > > getdtablesize is used internally, too. After this change, the values > returned by sysconf and getrlimit should be revisited as well. They will now return OPEN_MAX_MAX, as I think they should. The only question in my mind is whether to simplify the code by removing the calls to getdtablesize, something like this (untested): diff --git a/winsup/cygwin/resource.cc b/winsup/cygwin/resource.cc index 9e39d3a04..ac56acf8c 100644 --- a/winsup/cygwin/resource.cc +++ b/winsup/cygwin/resource.cc @@ -182,10 +182,7 @@ getrlimit (int resource, struct rlimit *rlp) __get_rlimit_stack (rlp); break; case RLIMIT_NOFILE: - rlp->rlim_cur = getdtablesize (); - if (rlp->rlim_cur < OPEN_MAX) - rlp->rlim_cur = OPEN_MAX; - rlp->rlim_max = OPEN_MAX_MAX; + rlp->rlim_cur = rlp->rlim_max = OPEN_MAX_MAX; break; case RLIMIT_CORE: rlp->rlim_cur = cygheap->rlim_core; diff --git a/winsup/cygwin/sysconf.cc b/winsup/cygwin/sysconf.cc index 001da96ad..d5d82bb4a 100644 --- a/winsup/cygwin/sysconf.cc +++ b/winsup/cygwin/sysconf.cc @@ -21,15 +21,6 @@ details. */ #include "cpuid.h" #include "clock.h" -static long -get_open_max (int in) -{ - long max = getdtablesize (); - if (max < OPEN_MAX) - max = OPEN_MAX; - return max; -} - static long get_page_size (int in) { @@ -520,7 +511,7 @@ static struct {cons, {c:CHILD_MAX}}, /* 1, _SC_CHILD_MAX */ {cons, {c:CLOCKS_PER_SEC}}, /* 2, _SC_CLK_TCK */ {cons, {c:NGROUPS_MAX}}, /* 3, _SC_NGROUPS_MAX */ - {func, {f:get_open_max}}, /* 4, _SC_OPEN_MAX */ + {cons, {c:OPEN_MAX_MAX}}, /* 4, _SC_OPEN_MAX */ {cons, {c:_POSIX_JOB_CONTROL}}, /* 5, _SC_JOB_CONTROL */ {cons, {c:_POSIX_SAVED_IDS}}, /* 6, _SC_SAVED_IDS */ {cons, {c:_POSIX_VERSION}}, /* 7, _SC_VERSION */ WDYT? Ken ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] Cygwin: getdtablesize: always return OPEN_MAX_MAX 2021-01-28 13:42 ` Ken Brown @ 2021-01-28 16:07 ` Corinna Vinschen 2021-01-28 16:13 ` Corinna Vinschen 2021-01-28 20:33 ` Ken Brown 0 siblings, 2 replies; 11+ messages in thread From: Corinna Vinschen @ 2021-01-28 16:07 UTC (permalink / raw) To: cygwin-patches On Jan 28 08:42, Ken Brown via Cygwin-patches wrote: > On 1/28/2021 5:20 AM, Corinna Vinschen via Cygwin-patches wrote: > > On Jan 27 21:51, Ken Brown via Cygwin-patches wrote: > > > According to the Linux man page for getdtablesize(3), the latter is > > > supposed to return "the maximum number of files a process can have > > > open, one more than the largest possible value for a file descriptor." > > > The constant OPEN_MAX_MAX is the only limit enforced by Cygwin, so we > > > now return that. > > > > > > Previously getdtablesize returned the current size of cygheap->fdtab, > > > Cygwin's internal file descriptor table. But this is a dynamically > > > growing table, and its current size does not reflect an actual limit > > > on the number of open files. > > > > > > With this change, gnulib now reports that getdtablesize and > > > fcntl(F_DUPFD) work on Cygwin. Packages like GNU tar that use the > > > corresponding gnulib modules will no longer use gnulib replacements on > > > Cygwin. > > > --- > > > winsup/cygwin/syscalls.cc | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc > > > index 5da05b18a..1f16d54b9 100644 > > > --- a/winsup/cygwin/syscalls.cc > > > +++ b/winsup/cygwin/syscalls.cc > > > @@ -2887,7 +2887,7 @@ setdtablesize (int size) > > > extern "C" int > > > getdtablesize () > > > { > > > - return cygheap->fdtab.size; > > > + return OPEN_MAX_MAX; > > > } > > > > getdtablesize is used internally, too. After this change, the values > > returned by sysconf and getrlimit should be revisited as well. > > They will now return OPEN_MAX_MAX, as I think they should. The only > question in my mind is whether to simplify the code by removing the calls to > getdtablesize, something like this (untested): But then again, what happens with OPEN_MAX in limits.h? Linux removed it entirely. Given we have such a limit and it's not flexible as on Linux, should we go ahead, drop OPEN_MAX_MAX entirely and define OPEN_MAX as 3200? One problem is that there are some applications in the wild which run loops up to either sysconf(_SC_OPEN_MAX) or OPEN_MAX to handle open descriptors. tcsh is one of them. It may slow done tcsh quite a bit if the loop runs to 3200 now every time. Corinna ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] Cygwin: getdtablesize: always return OPEN_MAX_MAX 2021-01-28 16:07 ` Corinna Vinschen @ 2021-01-28 16:13 ` Corinna Vinschen 2021-01-28 22:28 ` Ken Brown 2021-01-28 20:33 ` Ken Brown 1 sibling, 1 reply; 11+ messages in thread From: Corinna Vinschen @ 2021-01-28 16:13 UTC (permalink / raw) To: cygwin-patches On Jan 28 17:07, Corinna Vinschen via Cygwin-patches wrote: > On Jan 28 08:42, Ken Brown via Cygwin-patches wrote: > > On 1/28/2021 5:20 AM, Corinna Vinschen via Cygwin-patches wrote: > > > On Jan 27 21:51, Ken Brown via Cygwin-patches wrote: > > > > According to the Linux man page for getdtablesize(3), the latter is > > > > supposed to return "the maximum number of files a process can have > > > > open, one more than the largest possible value for a file descriptor." > > > > The constant OPEN_MAX_MAX is the only limit enforced by Cygwin, so we > > > > now return that. > > > > > > > > Previously getdtablesize returned the current size of cygheap->fdtab, > > > > Cygwin's internal file descriptor table. But this is a dynamically > > > > growing table, and its current size does not reflect an actual limit > > > > on the number of open files. > > > > > > > > With this change, gnulib now reports that getdtablesize and > > > > fcntl(F_DUPFD) work on Cygwin. Packages like GNU tar that use the > > > > corresponding gnulib modules will no longer use gnulib replacements on > > > > Cygwin. > > > > --- > > > > winsup/cygwin/syscalls.cc | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc > > > > index 5da05b18a..1f16d54b9 100644 > > > > --- a/winsup/cygwin/syscalls.cc > > > > +++ b/winsup/cygwin/syscalls.cc > > > > @@ -2887,7 +2887,7 @@ setdtablesize (int size) > > > > extern "C" int > > > > getdtablesize () > > > > { > > > > - return cygheap->fdtab.size; > > > > + return OPEN_MAX_MAX; > > > > } > > > > > > getdtablesize is used internally, too. After this change, the values > > > returned by sysconf and getrlimit should be revisited as well. > > > > They will now return OPEN_MAX_MAX, as I think they should. The only > > question in my mind is whether to simplify the code by removing the calls to > > getdtablesize, something like this (untested): > > But then again, what happens with OPEN_MAX in limits.h? Linux removed > it entirely. Given we have such a limit and it's not flexible as on > Linux, should we go ahead, drop OPEN_MAX_MAX entirely and define > OPEN_MAX as 3200? ...ideally by adding a file include/cygwin/limits.h included by include/limits.h, which defines __OPEN_MAX et al, as required. Corinna ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] Cygwin: getdtablesize: always return OPEN_MAX_MAX 2021-01-28 16:13 ` Corinna Vinschen @ 2021-01-28 22:28 ` Ken Brown 2021-01-29 19:23 ` Ken Brown 0 siblings, 1 reply; 11+ messages in thread From: Ken Brown @ 2021-01-28 22:28 UTC (permalink / raw) To: cygwin-patches On 1/28/2021 11:13 AM, Corinna Vinschen via Cygwin-patches wrote: > On Jan 28 17:07, Corinna Vinschen via Cygwin-patches wrote: >> On Jan 28 08:42, Ken Brown via Cygwin-patches wrote: >>> On 1/28/2021 5:20 AM, Corinna Vinschen via Cygwin-patches wrote: >>>> On Jan 27 21:51, Ken Brown via Cygwin-patches wrote: >>>>> According to the Linux man page for getdtablesize(3), the latter is >>>>> supposed to return "the maximum number of files a process can have >>>>> open, one more than the largest possible value for a file descriptor." >>>>> The constant OPEN_MAX_MAX is the only limit enforced by Cygwin, so we >>>>> now return that. >>>>> >>>>> Previously getdtablesize returned the current size of cygheap->fdtab, >>>>> Cygwin's internal file descriptor table. But this is a dynamically >>>>> growing table, and its current size does not reflect an actual limit >>>>> on the number of open files. >>>>> >>>>> With this change, gnulib now reports that getdtablesize and >>>>> fcntl(F_DUPFD) work on Cygwin. Packages like GNU tar that use the >>>>> corresponding gnulib modules will no longer use gnulib replacements on >>>>> Cygwin. >>>>> --- >>>>> winsup/cygwin/syscalls.cc | 2 +- >>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>> >>>>> diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc >>>>> index 5da05b18a..1f16d54b9 100644 >>>>> --- a/winsup/cygwin/syscalls.cc >>>>> +++ b/winsup/cygwin/syscalls.cc >>>>> @@ -2887,7 +2887,7 @@ setdtablesize (int size) >>>>> extern "C" int >>>>> getdtablesize () >>>>> { >>>>> - return cygheap->fdtab.size; >>>>> + return OPEN_MAX_MAX; >>>>> } >>>> >>>> getdtablesize is used internally, too. After this change, the values >>>> returned by sysconf and getrlimit should be revisited as well. >>> >>> They will now return OPEN_MAX_MAX, as I think they should. The only >>> question in my mind is whether to simplify the code by removing the calls to >>> getdtablesize, something like this (untested): >> >> But then again, what happens with OPEN_MAX in limits.h? Linux removed >> it entirely. Given we have such a limit and it's not flexible as on >> Linux, should we go ahead, drop OPEN_MAX_MAX entirely and define >> OPEN_MAX as 3200? > > ...ideally by adding a file include/cygwin/limits.h included by > include/limits.h, which defines __OPEN_MAX et al, as required. I'm not completely sure I follow. Do you mean include/cygwin/limits.h should contain #define __OPEN_MAX 3200 and include/limits.h should contain #define OPEN_MAX __OPEN_MAX ? For the sake of my education, could you explain the reason for this? Thanks. Ken ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] Cygwin: getdtablesize: always return OPEN_MAX_MAX 2021-01-28 22:28 ` Ken Brown @ 2021-01-29 19:23 ` Ken Brown 2021-02-01 9:42 ` Corinna Vinschen 0 siblings, 1 reply; 11+ messages in thread From: Ken Brown @ 2021-01-29 19:23 UTC (permalink / raw) To: cygwin-patches On 1/28/2021 5:28 PM, Ken Brown via Cygwin-patches wrote: > On 1/28/2021 11:13 AM, Corinna Vinschen via Cygwin-patches wrote: >> On Jan 28 17:07, Corinna Vinschen via Cygwin-patches wrote: >>> On Jan 28 08:42, Ken Brown via Cygwin-patches wrote: >>>> On 1/28/2021 5:20 AM, Corinna Vinschen via Cygwin-patches wrote: >>>>> On Jan 27 21:51, Ken Brown via Cygwin-patches wrote: >>>>>> According to the Linux man page for getdtablesize(3), the latter is >>>>>> supposed to return "the maximum number of files a process can have >>>>>> open, one more than the largest possible value for a file descriptor." >>>>>> The constant OPEN_MAX_MAX is the only limit enforced by Cygwin, so we >>>>>> now return that. >>>>>> >>>>>> Previously getdtablesize returned the current size of cygheap->fdtab, >>>>>> Cygwin's internal file descriptor table. But this is a dynamically >>>>>> growing table, and its current size does not reflect an actual limit >>>>>> on the number of open files. >>>>>> >>>>>> With this change, gnulib now reports that getdtablesize and >>>>>> fcntl(F_DUPFD) work on Cygwin. Packages like GNU tar that use the >>>>>> corresponding gnulib modules will no longer use gnulib replacements on >>>>>> Cygwin. >>>>>> --- >>>>>> winsup/cygwin/syscalls.cc | 2 +- >>>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>>> >>>>>> diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc >>>>>> index 5da05b18a..1f16d54b9 100644 >>>>>> --- a/winsup/cygwin/syscalls.cc >>>>>> +++ b/winsup/cygwin/syscalls.cc >>>>>> @@ -2887,7 +2887,7 @@ setdtablesize (int size) >>>>>> extern "C" int >>>>>> getdtablesize () >>>>>> { >>>>>> - return cygheap->fdtab.size; >>>>>> + return OPEN_MAX_MAX; >>>>>> } >>>>> >>>>> getdtablesize is used internally, too. After this change, the values >>>>> returned by sysconf and getrlimit should be revisited as well. >>>> >>>> They will now return OPEN_MAX_MAX, as I think they should. The only >>>> question in my mind is whether to simplify the code by removing the calls to >>>> getdtablesize, something like this (untested): >>> >>> But then again, what happens with OPEN_MAX in limits.h? Linux removed >>> it entirely. Given we have such a limit and it's not flexible as on >>> Linux, should we go ahead, drop OPEN_MAX_MAX entirely and define >>> OPEN_MAX as 3200? >> >> ...ideally by adding a file include/cygwin/limits.h included by >> include/limits.h, which defines __OPEN_MAX et al, as required. > > I'm not completely sure I follow. Do you mean include/cygwin/limits.h should > contain > > #define __OPEN_MAX 3200 > > and include/limits.h should contain > > #define OPEN_MAX __OPEN_MAX ? > > For the sake of my education, could you explain the reason for this? Trying to answer my own question, I guess the idea is to hide implementation details from viewers of limits.h. Is that right? I took a stab at this and am about to send a patchset. I'm not sure whether I made a reasonable choice of "et al" in "__OPEN_MAX et al". Ken ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] Cygwin: getdtablesize: always return OPEN_MAX_MAX 2021-01-29 19:23 ` Ken Brown @ 2021-02-01 9:42 ` Corinna Vinschen 0 siblings, 0 replies; 11+ messages in thread From: Corinna Vinschen @ 2021-02-01 9:42 UTC (permalink / raw) To: cygwin-patches On Jan 29 14:23, Ken Brown via Cygwin-patches wrote: > On 1/28/2021 5:28 PM, Ken Brown via Cygwin-patches wrote: > > > ...ideally by adding a file include/cygwin/limits.h included by > > > include/limits.h, which defines __OPEN_MAX et al, as required. > > > > I'm not completely sure I follow. Do you mean include/cygwin/limits.h > > should contain > > > > #define __OPEN_MAX 3200 > > > > and include/limits.h should contain > > > > #define OPEN_MAX __OPEN_MAX ? > > > > For the sake of my education, could you explain the reason for this? > > Trying to answer my own question, I guess the idea is to hide implementation > details from viewers of limits.h. Is that right? Yes, that was the idea, kind of like a poor mans include/bits dir on Linux... > I took a stab at this and > am about to send a patchset. I'm not sure whether I made a reasonable > choice of "et al" in "__OPEN_MAX et al". Sorry, I didn't mean to imply you will have to do that right away. It was just a thought to move over more values in later patches. Corinna ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] Cygwin: getdtablesize: always return OPEN_MAX_MAX 2021-01-28 16:07 ` Corinna Vinschen 2021-01-28 16:13 ` Corinna Vinschen @ 2021-01-28 20:33 ` Ken Brown 2021-02-01 9:50 ` Corinna Vinschen 1 sibling, 1 reply; 11+ messages in thread From: Ken Brown @ 2021-01-28 20:33 UTC (permalink / raw) To: cygwin-patches On 1/28/2021 11:07 AM, Corinna Vinschen via Cygwin-patches wrote: > On Jan 28 08:42, Ken Brown via Cygwin-patches wrote: >> On 1/28/2021 5:20 AM, Corinna Vinschen via Cygwin-patches wrote: >>> On Jan 27 21:51, Ken Brown via Cygwin-patches wrote: >>>> According to the Linux man page for getdtablesize(3), the latter is >>>> supposed to return "the maximum number of files a process can have >>>> open, one more than the largest possible value for a file descriptor." >>>> The constant OPEN_MAX_MAX is the only limit enforced by Cygwin, so we >>>> now return that. >>>> >>>> Previously getdtablesize returned the current size of cygheap->fdtab, >>>> Cygwin's internal file descriptor table. But this is a dynamically >>>> growing table, and its current size does not reflect an actual limit >>>> on the number of open files. >>>> >>>> With this change, gnulib now reports that getdtablesize and >>>> fcntl(F_DUPFD) work on Cygwin. Packages like GNU tar that use the >>>> corresponding gnulib modules will no longer use gnulib replacements on >>>> Cygwin. >>>> --- >>>> winsup/cygwin/syscalls.cc | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc >>>> index 5da05b18a..1f16d54b9 100644 >>>> --- a/winsup/cygwin/syscalls.cc >>>> +++ b/winsup/cygwin/syscalls.cc >>>> @@ -2887,7 +2887,7 @@ setdtablesize (int size) >>>> extern "C" int >>>> getdtablesize () >>>> { >>>> - return cygheap->fdtab.size; >>>> + return OPEN_MAX_MAX; >>>> } >>> >>> getdtablesize is used internally, too. After this change, the values >>> returned by sysconf and getrlimit should be revisited as well. >> >> They will now return OPEN_MAX_MAX, as I think they should. The only >> question in my mind is whether to simplify the code by removing the calls to >> getdtablesize, something like this (untested): > > But then again, what happens with OPEN_MAX in limits.h? Linux removed > it entirely. Given we have such a limit and it's not flexible as on > Linux, should we go ahead, drop OPEN_MAX_MAX entirely and define > OPEN_MAX as 3200? Makes sense to me. > One problem is that there are some applications in the wild which run > loops up to either sysconf(_SC_OPEN_MAX) or OPEN_MAX to handle open > descriptors. tcsh is one of them. It may slow done tcsh quite a bit > if the loop runs to 3200 now every time. I don't use tcsh. Is it easy to test this? Ken ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] Cygwin: getdtablesize: always return OPEN_MAX_MAX 2021-01-28 20:33 ` Ken Brown @ 2021-02-01 9:50 ` Corinna Vinschen 2021-02-01 10:46 ` Corinna Vinschen 0 siblings, 1 reply; 11+ messages in thread From: Corinna Vinschen @ 2021-02-01 9:50 UTC (permalink / raw) To: cygwin-patches On Jan 28 15:33, Ken Brown via Cygwin-patches wrote: > On 1/28/2021 11:07 AM, Corinna Vinschen via Cygwin-patches wrote: > > One problem is that there are some applications in the wild which run > > loops up to either sysconf(_SC_OPEN_MAX) or OPEN_MAX to handle open > > descriptors. tcsh is one of them. It may slow done tcsh quite a bit > > if the loop runs to 3200 now every time. > > I don't use tcsh. Is it easy to test this? I just checked the source. In the olden days, before the invention of close-on-exec, tcsh closed all descriptors > 2 up to OPEN_MAX prior to starting any executable. With close-on-exec this happens only at startup and after an error occured. So testing should be easy: The tcsh startup may be noticably slower. Corinna ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] Cygwin: getdtablesize: always return OPEN_MAX_MAX 2021-02-01 9:50 ` Corinna Vinschen @ 2021-02-01 10:46 ` Corinna Vinschen 0 siblings, 0 replies; 11+ messages in thread From: Corinna Vinschen @ 2021-02-01 10:46 UTC (permalink / raw) To: cygwin-patches On Feb 1 10:50, Corinna Vinschen via Cygwin-patches wrote: > On Jan 28 15:33, Ken Brown via Cygwin-patches wrote: > > On 1/28/2021 11:07 AM, Corinna Vinschen via Cygwin-patches wrote: > > > One problem is that there are some applications in the wild which run > > > loops up to either sysconf(_SC_OPEN_MAX) or OPEN_MAX to handle open > > > descriptors. tcsh is one of them. It may slow done tcsh quite a bit > > > if the loop runs to 3200 now every time. > > > > I don't use tcsh. Is it easy to test this? > > I just checked the source. In the olden days, before the invention of > close-on-exec, tcsh closed all descriptors > 2 up to OPEN_MAX prior to > starting any executable. > > With close-on-exec this happens only at startup and after an error > occured. > > So testing should be easy: The tcsh startup may be noticably slower. I checked this right now and I don't see a noticable, i. .e, any, difference. Corinna ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2021-02-01 10:46 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-01-28 2:51 [PATCH] Cygwin: getdtablesize: always return OPEN_MAX_MAX Ken Brown 2021-01-28 10:20 ` Corinna Vinschen 2021-01-28 13:42 ` Ken Brown 2021-01-28 16:07 ` Corinna Vinschen 2021-01-28 16:13 ` Corinna Vinschen 2021-01-28 22:28 ` Ken Brown 2021-01-29 19:23 ` Ken Brown 2021-02-01 9:42 ` Corinna Vinschen 2021-01-28 20:33 ` Ken Brown 2021-02-01 9:50 ` Corinna Vinschen 2021-02-01 10:46 ` Corinna Vinschen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).