#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 |
-----------------------+----------------------------------------------------
Changes (by cavedon):
* status: closed => reopened
* field_os: => all
* resolution: fixed =>
Comment:
Thanks for fixing this issue. We are getting closer to having qutecom
reliably working with external libpruple!
However I noticed that there is race condition: PurpleIMFactory needs to
wait for libpurple to be initialized before continuing, because it will
make calls into libpurple API.
I am attaching a patch to fix this. I am not an expert on glib, so feel
free to rewrite it if there is a better way to do that.
However, I have realized that there are many other calls into libpurple
API that are not done in the proper thread, but come from the main qutecom
thread, and this violates libpurple specification. However, it would not
make sense to wrap every possible calls with some code to schedule it on
the glib thread with the glib main loop. So, in the end, probably the only
viable via to *ensure* thread-safety in libpurple would be to merge the
two loops (i.e. make libpurple use the main application loop).
--
Ticket URL: <http://trac.qutecom.org/ticket/175#comment:4>
QuteCom <http://trac.qutecom.org>
_______________________________________________
QuteCom-dev mailing list
QuteCom-dev@lists.qutecom.org
http://lists.qutecom.org/mailman/listinfo/qutecom-dev
