Unfortunately this error can be given by GnuTLS even though the
underlying stream still has data available. So stop trusting this value
and keep track of the underlying stream explicitly.
The generally recommended way is to include it from source files, not
headers. We had a mix of both. Let's try to be consistent and follow the
recommended way.
Major restructuring of how streams work. Neither input nor output
streams are now blocking. This avoids stalling the rest of the client or
server when a peer is slow or unresponsive.
Note that this puts an extra burden on users of streams to make sure
they are allowed to do their work once the underlying transports are
ready (e.g. monitoring fds).
Provides safety against them accidentally becoming negative because
of bugs in the calculations.
Also does the same to CharArray and friends as they were strongly
connection to the stream objects.
This allows us to simplify things by getting rid of some old
compatibility code. People should really be using current versions
of GnuTLS anyway to stay secure.
Refactor the TLS code so that the push/pull functions are aware of their
containing stream object. This is in preparation for supporting GnuTLS 3.x.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4921 3789f03b-4d11-0410-bbf8-ca57d06f2519
Pierre Ossman
Adam Tkac
Constantin Kaplinsky