[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#18396: 24.3.1; On windows, process-send-string can freeze Emacs

From: Jorgen Schaefer
Subject: bug#18396: 24.3.1; On windows, process-send-string can freeze Emacs
Date: Wed, 3 Sep 2014 20:43:07 +0200

On Wed, 03 Sep 2014 21:03:00 +0300
Eli Zaretskii <address@hidden> wrote:

> > From: Jorgen Schaefer <address@hidden>
> > Date: Wed, 03 Sep 2014 18:58:11 +0200
> > 
> > A user's bug report[1] on my project Elpy has revealed an apparent
> > bug in Emacs.
> I'm not sure it is a bug in Emacs.

After your explanation, I'm not so sure, either.
> > Elpy starts a Python process using `start-process' with
> > `process-connection-type' set to nil, `default-directory' set to
> > "/", and an unchanged coding system.
> Using "/" as the default directory on Windows is a bad idea, as that
> is not a fully-qualified absolute file name.

What would be the equivalent for "out of the way and not blocking any
mount point" (or equivalent) on Windows?

> Looks like the write to the pipe never returned.  This could be
> because the pipe is full and is not being read from the other end
> (Windows pipes have 4K buffers, and you show above more than 6K of
> data).

That is quite likely the explanation. The Python process does the
equivalent of a REPL, reading one RPC call, evaluating it, and writing
the response. If in the duration of that evaluation Emacs sends more
than 4k of data, it will hang. If the response is larger than 4k,
Python in turn will hang. Resulting in a deadlock.

Am I missing something?

The same would happen on Unix, except the buffer size is much larger,
meaning it's a lot less likely.

I guess the Python process could use threading to avoid this.

Does Emacs have a chance to check for a pipe to be writable before
doing so? The whole process blocking like this feels a bit weird.

> > I'm a bit at a loss now as to how to continue debugging this.
> The obvious way: attach a debugger to Emacs and see where it is hung
> or waiting.  It is important to ask the user to produce backtraces
> from all the threads, because at least 2 threads are involved in
> interaction with a subprocess on MS-Windows.

Thanks. I'll ask, though I'm not sure if the user has a debugger


reply via email to

[Prev in Thread] Current Thread [Next in Thread]