#175: libpurple API called from different threads
-----------------------+----------------------------------------------------
Reporter: cavedon | Owner: vadim
Type: defect | Status: reopened
Priority: critical | Milestone: QuteCom 2.2-RC4
Component: misc | Version: 2.2
Resolution: | Keywords:
Field_os: all |
-----------------------+----------------------------------------------------
Comment(by cavedon):
The patch itself for making the Thread class run on a glib event loop is
pretty simple (thread-glib.patch) and seems to work.
The patch for making libpurple use the model thread brings some issues I
have not solved yet. I am attching the patch so far (libpurple-model-
thread.patch) for reference, even though there is some memory corruption
happening with libpurple and qutecom segfaults.
Some comments:
* PurpleIMFactory is called from the thread that will run the event loop,
so no need to schedule an event for calling purple_core_{init,quit}()
* We need to create the glib main loop before creating the
PurpleIMFactory
* We do not want to run on the default glib loop (as Qt ill probably use
it), so we create our own GMainContext and call glib API specifying our
own context
There is still an issue in the way timeouts are implemented in qutecom.
Instead of the callback being called in the same thread after the given
timeout, a Timer object is created, which spawns a new thread, which
sleeps for the given time and then invokes the callback. The problem is
that the callback is invoked in the Timer thread, which is *bad* for
libpurple.
Because of that I was getting crash, and had to reschedule an event in the
model thread from the callback (see model/connect/Connect.cpp). However I
do not know how to easily find all callbacks which need this treatment.
Another possibility would be to change Timer implementation and map
qutecom timeouts to glib timeouts in the model thread. The patch is not
complicated. I like this idea also because we get rid of that bunch of
threads being created and killed. However, I am not sure this will not
bring other issues, as the behavior of the callback being called from
another thread is documenebted in the Timer API...
Do you have any idea?
Thanks!
--
Ticket URL: <http://trac.qutecom.org/ticket/175#comment:12>
QuteCom <http://trac.qutecom.org>
_______________________________________________
QuteCom-dev mailing list
[email protected]
http://lists.qutecom.org/mailman/listinfo/qutecom-dev
