[sr #107763] Running GnuTLS in non-blocking mode.
INVALID.NOREPLY at gnu.org
Wed Aug 3 09:01:37 CEST 2011
Summary: Running GnuTLS in non-blocking mode.
Submitted by: cybear
Submitted on: Wed Aug 3 07:01:37 2011
Category: Core library
Priority: 5 - Normal
Severity: 3 - Normal
Assigned to: None
Discussion Lock: Any
Operating System: Microsoft Windows
I think this is a variant of #107660.
I have just updated from version 2.10.1 to 2.12.7 and my application has
I am running one thread to handle all the socket communication both secure
through GnuTLS and unsecure on sockets.
All sockets have been set into non-blocking mode.
The main loop in the work thread defines which sockets to check for ready for
read and write and then suspends on the select() call.
When returned from the select() call I will read from the socket which has
data to read.
This strategy worked fine with version 2.10.1 but is broken in version
Because: (as far as I can debug)
I sent from the client 231 bytes of data 115 bytes of header and 116 bytes of
data (my protocol)
I call gnutls_record_recv and ask for 115 bytes, because I want to read my
header and determine what to do after that.
Then I again mark the socket so select() will check it for new data (ready for
read on the raw socket) waiting for my 116 byte of data. And the work thread
suspends on the select() call.
But in version 2.12.7 no new data arrives on the socket because it was read
and buffered on the first call to gnutls_record_recv. SO my work thread grinds
to a halt on the socket gnutls buffers data.
Yes I can see there is a call to the gnutls_record_check_pending() but this
will cause that the way of reading will be different between secure and
And the comments in the code on gnutls_record_recv clearly indicates that the
intention is for the function to work like recv().
Reply to this item at:
Message sent via/by Savannah
More information about the Gnutls-devel