[Help-gnutls] Re: Odd issue with gnu-tls 2.6.4 running as a subprocess of emacs-23 on Windows XP

[Simon Josefsson]

Iver Odin Kvello <iverodin at gmail.com> writes:

>> Yes, gnutls 2.6.x and earlier uses a broken emulation of select() which
>> likely does have problems, and there is also some buffering problems
>> that can result in CRLF confusion.
>>
>> Gnutls 2.7.x will fix this, but unfortunately there is a small piece
>> missing to prevent it from working under Windows right now...  this is
>> probably the biggest remaining issue to fix before 2.8.x so it is a
>> priority.
>
> I debugged the issue a bit more over easter, and found that the hang
> is actually in the read from stdin in cli.c when there is no input
> ready on stdin. Apparently the select() emulation for normal
> filehandles using MsgWaitForMultipleObjects returns stdin as ready no
> matter if there is input ready there or not - at least when run like
> this. Adding extra newlines seems to fix this by ensuring that there
> is some input to be read most of the time, helped along a bit by some
> buffering; but of course it will be defeated by  bad timing.
>
> I don't know why waitformultipleobjects behaves like this; I don't
> really know win32. I was thinking perhaps the easiest way of fixing
> this might be to just avoid select() for stdin and just handle stdin
> in a dedicated thread on windows, but I haven't tested that yet. Or I
> could just wait for 2.8.x :)

The solution in 2.8.x. will be to avoid select() and use poll() instead,
for which there is (allegedly) a more reliable wrapper implementation in
gnulib:
http://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/poll.c

/Simon