[Help-gnutls] push/pull functions

[Robin Redeker]

On Wed, Sep 26, 2007 at 11:08:02AM +0300, Nikos Mavrogiannopoulos wrote:
> On Wednesday 26 September 2007, Robin Redeker wrote:
> > Hi!
> 
> > I have a (maybe not so?) simple question:
> > Can I call gnutls_record_recv/gnutls_record_send safely while I'm in a
> > push/pull callback?
> 
> As long as you don't use the same session, it should be safe.
> 
> > The reason I'm asking is that I want to make bindings for GNU Smalltalk,
> > which has support for non-preemtive multiple threads of execution.
> 
> gnutls can be used with multiple threads, as long as the gcrypt callbacks are 
> set and the same session is not accessed by multiple threads.

Well, usually you have a writer and a reader thread per session. Will
those interfere?  Or does it mean that I'll have to use non-blocking I/O
semantics to ensure that there are not two threads doing a recv and send
at the same time?

Also the threads in smalltalk are not "real" OS level processes, they
are much more Coroutines than something else.

Mostly it will look like this: one thread waits for new data with a
read(2), usually the smalltalk core does a select() and execute other
pseudo-threads while the reading thread is suspended. In one of the
other threads someone uses gnutls_record_send to send something.

And I wonder whether that _send somehow will interfere with the still
waiting reader (which means the thread of execution for the reader is
still blocked in the pull callback).

There certainly wont be a recursive call to gnutls_record_recv from any
other thread than the reader thread.

I hope you understand what I mean from that explanation. Please ask if
it was not clear.


I've looked at the source of gnutls, and the writing and reading seems
to be mostly seperate from what I've seen. I'm just wondering whether a
gnutls_record_send () maybe somehow will invoke a read operation which
then calls yet another pull-callback (while some other thread already
has a pull-callback on hold).

> > What if some kind of re-handshake happens while I call
> > gnutls_record_recv? Will GnuTLS detect that it is still waiting for the
> > callback to read to return?
> 
> A rehandshake will be detected by the return value of gnutls_record_recv(). It 
> is in-band data so it should procceed normally.

Ah, ok.

> > And there is also another issue I stepped over while testing. I somehow
> > could't get the anonymous client example to work with gnutls-serv.
> > I've tried running the server with:
> >    gnutls-serv -p 12331 --kx "Anon DH"
> >    gnutls-serv -p 12331 --kx "Anon DH" -g
> >    gnutls-serv -p 12331 --kx "Anon DH" --dhparams /tmp/dh.pem (with a
> >    properly initialized dh.pem)
> 
> Thank you for reporting this. It seems that it was a bug in the handshake 
> function and couldn't negotiate anonymous DH if a certificate wasn't set. It 
> must be corrected in the git repository (and attached patch).

Yes, the patch fixes it. Thanks!


And thanks for the quick response!


Robin