#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 nikita):
The patchset I was pointing you is to solve
http://trac.qutecom.org/ticket/173, it wasn't related to the current
report. I pointed it because it's in some way related to the current
report. I don't really know why we have that bug, but it's seems to work
if Qt is using libpurple eventloop, anyway it's just a creepy workaround
until we decide how to resolve imwrapper problem.
About imwrapper thread-safety, I'm afraid of that I'm not a glib expert
too, I agree that we need to rewrite the imwrapper <-> model calls or to
merge libpurple eventloop with the model loop. But it's certainly a lot of
changes, we are thinking about the best way to do it, merging both loops
with boost (how difficult it will be considering the actual imwrapper and
libpurple glib requirements ?), keeping two separated threads and using Qt
signals/slots for communication.
All suggestions or comments are welcome.
About your patch, he will be useful since mine his just concerning Qt with
glib under linux.
--
Ticket URL: <http://trac.qutecom.com/ticket/175#comment:10>
QuteCom <http://trac.qutecom.com>
_______________________________________________
QuteCom-dev mailing list
[email protected]
http://lists.qutecom.org/mailman/listinfo/qutecom-dev
