blueman <NOSPAM@xxxxxxxxxx> writes:
> blueman <NOSPAM@xxxxxxxxxx> writes:
>> Uday S Reddy <uDOTsDOTreddy@xxxxxxxxxxxxx> 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
1. "cat > tempfile"
- Doesn't crash regardless of input size
- 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