Re: process_send_string blocks?

[Eli Zaretskii]

> From: Stephen Leake <address@hidden>
> Date: Sat, 06 Sep 2014 08:11:13 -0500
> 
> >> On reading process.c, I believe this should not happen, if the OS supports
> >> EWOULDBLOCK. 
> >> 
> >> Is that true, even when there is only one call to process-send-string that
> >> sends the entire buffer?
> >
> > Not sure what are you asking here, since you say you've read the code
> > and saw the handling of EWOULDBLOCK.
> 
> Because it is often easy to misunderstand code that I am reading for the
> first time. For example, I completely missed the threading stuff you
> talk about below.

The threads I described are below the level you see in process.c, they
are Windows-specific implementations of 'read', 'write', and 'pselect'
semantics.  On the process.c level, the code handles EWOULDBLOCK on
write, by queuing the rest of the stuff and looping while reading
input.  This is independent of what the lower levels do.

> >> I'm running on Windows 7, using the Windows binary
> >> emacs-23.4-bin-i386.zip from the FSF FTP site.
> >> 
> >> Is EWOULDBLOCK supported on this system?
> >
> > Not on writes to pipes, AFAIK.
> 
> Ah, then that's the problem. Hmm, except below you seem to be saying
> maybe it's not?

I don't know.  It could be.  The implementation of Emacs subprocesses
on Windows is non-trivial, and I cannot claim I have a 100% clear
picture of everything that's going on there.  In addition, there are
other threads that could potentially be involved.

So it's possible that the deadlock is very simple, but there could be
surprises.  Only debugging will tell.

> I have a reliable reproducer, which I can easily simplify.

Please do simplify it and post it.  Having a way of debugging this by
several people will definitely make the process more efficient, and
probably produce a higher quality solution.

Btw, do you see the problem in "emacs -Q"?

Thanks.