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 _______________________________________________ Help-gnutls mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnutls
