Re: gnutls_handshake() thread problem

[Jay Anra]

answering your question: 'Do you call 
gnutls_handshake in parallel from different threads?'

Sort of, although not explicitly. It's a consequence of using asynchronous sockets. The concurrency comes
from the interrupt generated by the SIGIO signal, which gets sent to my process when data arrives on the socket.
Obviously I have no control over the timing of this signal, so it may cause concurrent calls to gnutls_handshake()
or it may not.

My point is that if you support asynchronous sockets, you need to stop concurrent calls or advertise the fact that 
the programmer needs to take action to stop it.

regards

Jay

On Wed, Nov 17, 2010 at 11:45 AM, Nikos Mavrogiannopoulos <address@hidden> wrote:

I don't understand what the problem is there. Do you call
gnutls_handshake in parallel from different threads? In that case
using a mutex is the right thing. We don't support concurrent
execution of gnutls_handshake from parallel threads for the same
session.

regards,
Nikos

On Wed, Nov 17, 2010 at 9:54 AM, Jay Anra <address@hidden> wrote:
> On 21 Oct I reported a problem I was having with inconsistent errors that
> appeared to be connected with libgcrypt and asynchronous sockets.
>
> It turns out the problem was not specifically libgcrypt but
> gnutls_handshake().
>
> What was happening was that the socket interrupt was calling
> gnutls_handshake() with a response from the server, interrupting the
> previous call to gnutls_handshake() that had not yet returned. The interrupt
> call to gnutls_handshake() obviously conflicting with the previous
> incomplete call to gnutls_handshake() and causing all sorts of inconsistent
> errors.
>
> I have used a mutex to protect gnutls_hansdshake() and the problems have
> gone away.
>
> Would it be possible to build protection into the library for this?
>

> _______________________________________________
> Help-gnutls mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/help-gnutls
>
>