[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [patch] Fix various bugs when using the gnutls async API
From: |
Sjoerd Simons |
Subject: |
Re: [patch] Fix various bugs when using the gnutls async API |
Date: |
Tue, 17 Aug 2010 17:26:38 +0100 |
On Tue, 2010-08-17 at 17:55 +0200, Nikos Mavrogiannopoulos wrote:
> On 08/11/2010 03:49 PM, Sjoerd Simons wrote:
> > Hi,
> >
> > Our XMPP library (wocky) uses gnutls in a quite heavily async way, which
> > unfortunately seems to have triggered some bugs in the lastest
> > versions :/. Some patches for git HEAD attached, which seems to fix
> > things nicely for me.
> >
> > Some extra comments for some of the patches:
> > * 0003-Remember-the-amount-of-user-data-we-re-sending-out.patch
> > I guess It could be argued that this information should be stored
> > inside the record_send_buffer instead of in the session internal
> > struct directly. I'm happy to change the patch around to do just
> > that :)
>
> Hello Sjoerd,
> Thanks for the patches. I've applied 1 and 2.
Thanks
> But on 3 I cannot get what was the issue that mandated the change. Why you
> need the user
> length instead of the byte length?
gnutls_record_send is documented to return the number of bytes send (by
the user!), so the failure case is currently like this:
gnutls_record_send () => -EAGAIN
gnutls_record_send () => byte_length
Where byte_lenght is what at that point is still left in the
record_send_buffer, it's not related to the data the user was sending.
> I am also wondering why the test program mini-egain that forces the pull
> function to return eagain now and then, it didn't trigger the errors you
> see. How do you trigger those issues?
I guess pure luck in the case of running mini-egain ? In our case every
pull and push will first return EAGAIN and only on the second call
succeed, so it will stress all the code-patch related to EAGAIN.
--
Sjoerd Simons <address@hidden>
Collabora Ltd.