Message ID | pull.553.v2.git.1581956750001.gitgitgadget@gmail.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [v2] mingw: workaround for hangs when sending STDIN | expand |
On Mon, Feb 17, 2020 at 11:26 AM Alexandr Miloslavskiy via GitGitGadget <gitgitgadget@gmail.com> wrote: > diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh > +test_expect_success 'stash handles large files' ' > + x=0123456789abcde\n && # 16 Did you intend for the \n in this assignment to be a literal newline? Every shell with which I tested treats it instead as an escaped 'n'. > + x=$x$x$x$x$x$x$x$x && # 128 > + x=$x$x$x$x$x$x$x$x && # 1k > + x=$x$x$x$x$x$x$x$x && # 8k > + x=$x$x$x$x$x$x$x$x && # 64k > + x=$x$x$x$x$x$x$x$x && # 512k > + x=$x$x$x$x$x$x$x$x && # 4m > + x=$x$x && # 8m > + echo $x >large_file.txt && > + unset x && # release memory By the way, are the embedded newlines actually important to the test itself, or are they just for human consumption if the test fails? I ask because I was curious about how other tests create large files, and found that a mechanism similar to your original (but without the pitfalls) has been used. For instance, t1050-large.sh uses: printf "%2000000s" X >large1 && which is plenty portable and (presumably) doesn't have such demanding memory consumption.
Eric Sunshine <sunshine@sunshineco.com> writes: > ... For instance, t1050-large.sh uses: > > printf "%2000000s" X >large1 && > > which is plenty portable and (presumably) doesn't have such demanding > memory consumption. Yes, I had the exact same reaction to echoing large string with literal backslash-en in it ;-) Thanks for reviewing and teaching.
On 17.02.2020 18:24, Eric Sunshine wrote: >> + x=0123456789abcde\n && # 16 > > Did you intend for the \n in this assignment to be a literal newline? > Every shell with which I tested treats it instead as an escaped 'n'. I'm such a novice shell script writer :( Yes, I intended a newline. > By the way, are the embedded newlines actually important to the test > itself, or are they just for human consumption if the test fails?I > ask because I was curious about how other tests create large files, > and found that a mechanism similar to your original (but without the > pitfalls) has been used. For instance, t1050-large.sh uses: > > printf "%2000000s" X >large1 && > > which is plenty portable and (presumably) doesn't have such demanding > memory consumption. They are not important to the test; the test only needs to internally have a 8+ mb patch. This only comes from my feeling that super-large lines could cause other unexpected things, such as hitting various completely reasonable limits and/or causing unwanted slowdowns. Frankly, I didn't test. Frankly, I already had concerns about adding the test. Now I have re-evaluated things and finally decided to move the test into commit message instead. With it, all compatibility etc questions are resolved.
diff --git a/compat/poll/poll.c b/compat/poll/poll.c index 0e95dd493c9..afa6d245846 100644 --- a/compat/poll/poll.c +++ b/compat/poll/poll.c @@ -139,22 +139,10 @@ win32_compute_revents (HANDLE h, int *p_sought) INPUT_RECORD *irbuffer; DWORD avail, nbuffer; BOOL bRet; - IO_STATUS_BLOCK iosb; - FILE_PIPE_LOCAL_INFORMATION fpli; - static PNtQueryInformationFile NtQueryInformationFile; - static BOOL once_only; switch (GetFileType (h)) { case FILE_TYPE_PIPE: - if (!once_only) - { - NtQueryInformationFile = (PNtQueryInformationFile)(void (*)(void)) - GetProcAddress (GetModuleHandleW (L"ntdll.dll"), - "NtQueryInformationFile"); - once_only = TRUE; - } - happened = 0; if (PeekNamedPipe (h, NULL, 0, NULL, &avail, NULL) != 0) { @@ -166,22 +154,9 @@ win32_compute_revents (HANDLE h, int *p_sought) else { - /* It was the write-end of the pipe. Check if it is writable. - If NtQueryInformationFile fails, optimistically assume the pipe is - writable. This could happen on Win9x, where NtQueryInformationFile - is not available, or if we inherit a pipe that doesn't permit - FILE_READ_ATTRIBUTES access on the write end (I think this should - not happen since WinXP SP2; WINE seems fine too). Otherwise, - ensure that enough space is available for atomic writes. */ - memset (&iosb, 0, sizeof (iosb)); - memset (&fpli, 0, sizeof (fpli)); - - if (!NtQueryInformationFile - || NtQueryInformationFile (h, &iosb, &fpli, sizeof (fpli), - FilePipeLocalInformation) - || fpli.WriteQuotaAvailable >= PIPE_BUF - || (fpli.OutboundQuota < PIPE_BUF && - fpli.WriteQuotaAvailable == fpli.OutboundQuota)) + /* It was the write-end of the pipe. Unfortunately there is no + reliable way of knowing if it can be written without blocking. + Just say that it's all good. */ happened |= *p_sought & (POLLOUT | POLLWRNORM | POLLWRBAND); } return happened; diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh index ea56e85e70d..ed23cd6a7f3 100755 --- a/t/t3903-stash.sh +++ b/t/t3903-stash.sh @@ -1285,4 +1285,19 @@ test_expect_success 'stash handles skip-worktree entries nicely' ' git rev-parse --verify refs/stash:A.t ' +test_expect_success 'stash handles large files' ' + x=0123456789abcde\n && # 16 + x=$x$x$x$x$x$x$x$x && # 128 + x=$x$x$x$x$x$x$x$x && # 1k + x=$x$x$x$x$x$x$x$x && # 8k + x=$x$x$x$x$x$x$x$x && # 64k + x=$x$x$x$x$x$x$x$x && # 512k + x=$x$x$x$x$x$x$x$x && # 4m + x=$x$x && # 8m + echo $x >large_file.txt && + unset x && # release memory + + git stash push --include-untracked -- large_file.txt +' + test_done