Iver Odin Kvello <[email protected]> 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 _______________________________________________ Help-gnutls mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnutls
