🚀 go-pugleaf

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?

>
> The problem must be because you are generating more than a 64K page of
> output...
>
> The problem is then in the 2-line of code that reads the output from the
> process.
>
> As I mentioned in another thread, I think the whole way output is done
> is messed up. Particularly in the asynchronous case where if you have a
> long process, then minutes later, when the process completes and you
> have moved on to another email, you get switched back without warning to
> the output buffer often in mid-typing stream. Also, I think one should
> have flexibility over what to name the buffer, whether to display it,
> etc.
>
> But I am hesitant to code changes unless I know that you and others are
> on-board with my suggested changes. Please see the other thread for my
> proposed way to change with relatively minimal if any impact on current
> usage.
>
>>
>> If you look up the ELisp manual section on "Receiving output from
>> processes", you should be able to code this more safely.
>>
>> Cheers,
>> Uday