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

[Iver Odin Kvello]

> 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 :)

Regards,
Iver