I realize this question has been posted in various forms and shapes
over the past few years, but I'm interested in an up-to-date answer.
The Gloox FAQ states the following:
>
> All functions are reentrant. No state is kept in shared or global variables.
>
> gloox is thread-safe in that there are neither shared memory nor global
> variables. However, write access to gloox objects from multiple threads needs
> appropriate synchronization. In gloox 0.9, access to TCP send() and recv() as
> well as SOCKS5BytestreamServer is synchronized internally.
My application is multi-threaded and e.g. MessageSessions get passed
around to the various places in the application. Am I to understand it
such that calling MessageSession::send() is thread-safe, but calling
other functions, such as ClientBase::disposeMessageSession(), is
unsafe? In the latter case, I see the following scenario play out:
Thread 1: MessageSession::handleMessage() is called.
Thread 2: Decides to close the message session object and calls
ClientBase::disposeMessageSession().
Thread 1: MessageSession::handleMessage() is suddenly working with a
deleted object.
The reason I bring this up is that I expect most GUI applications to
call recv() in a separate thread, which means callbacks and so on are
being delivered in the context of that thread as well. However,
closing a session (i.e. calling ClientBase::disposeMessageSession())
might very likely happen in the context of the main GUI thread, and
not the thread that's driving Gloox. What's the recommended approach
to deal with such a situation if Gloox doesn't provide a way to
synchronize access to the various objects? For instance, I could
potentially be calling MessageSession::setThreadID() while Gloox is
also reading/writing to it.
/ Soren