🚀 go-pugleaf

blueman <NOSPAM@nospam.com> writes:

> blueman <NOSPAM@nospam.com> writes:
>
>> Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes:
>>> blueman wrote:
>>
>>> I played with some variations of it, and finally realized that the
>>> problem must be the handling of the output.  In your test process, the
>>> output is going to the testfile.  If I just use 'cat' as the command
>>> instead of 'cat > testfile', then sure enough the problem
>>> reappears. It starts hanging somewhere above 64K.
>>
>> Ahhhh... that's why I was asking for details on exactly what commands
>> you used.
>> That would explain our differences since cat'ing to a file (or running
>> through spamassassin which is another test I did) generates only a
>> handful of bytes of output.
>
> I can now reproduce your problem but it seems to happen *only* on
> Windows. Interestingly, it happens using either bash.exe (Cygwin's
> shell) or the Windows-like shell (cmdproxy.exe). So, seems to be
> something different about how Emacs on Windows deals with processes
>
> Interestingly, when I use edebug to step through the function, it
> doesn't hang as long as no single email is too large. If there is an
> email larger than 64K, it hangs on the command:
> (process-send-region process (nth 0 region) (nth 1 region)))
>
> So, it seems like there is some type of size/timing issue going on
> here. Where a process cannot accept more than 64K either in one batch or
> in batches too closely spaced together in time.
>
> And I can replicate it by running the following block from the
> minibuffer on a buffer >64K in length (doesn't need to be mail) for
> different values of NNN. The precise value where it hangs seems to
> differ for different files but it always seems to be <64K (and it may be
> due to the coding system).
>
> (progn (setq process (start-process "test" "tempbuff" shell-file-name
> shell-command-switch "cat")) (process-send-region process (point-min) NNN))
>
>
> NB.Just for a lark, I tested "cat" (without testfile) on a 50MB folder with
> 2500 emails on Linux -- took about a minute on my 7 year old machine,
> but worked flawlessly.
>
> So, clearly a bug in Emacs and nothing to do with VM or
> vm-pipe-messages-to-command etc. Probably should be reported to the
> Emacs team. Also, doesn't seem to be any way to fix it neatly unles you
> would want to break up writes into smaller chunks (which is not that
> bad in and of itself) and then wait for some arbitray amount of time
> between writes (this seems just downright ugly & unnatural).
>
> BTW are you using ntEmacs or cygwin Emacs?
>

Interestingly, the problem is not simply related to either the size of
the input or the size of the output. (The following is all only true for
Windows):

1. "cat > tempfile"
   - Doesn't crash regardless of input size

2. "cat"
   - Seems to hang if input region >64K or so (sometimes a few K less,
     sometimes a few hundred bytes more)

3. "cat file"
   - Doesn't seem to work regardless of size of input region or file
     (but works fine on Linux