#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):
Replying to [comment:10 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.
Ah, ok, sorry for the misunderstanding.
> 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.
From what I understood, libpurple does not strictly need a glib event
loop. You just need to provide some callback that libpurple will use to
interface with your even loop.
http://developer.pidgin.im/doxygen/dev/html/struct__PurpleEventLoopUiOps.html
The problem of interfacing libpurple with qutecom model loop is that
libpurple needs notification about events on file descripts, while the
custom boost-based loop does not support it (AFAICT).
IMHO, it does not make sense to extend the current model loop, and
reinvent another even-loop. I think the best way would be to change the
model loop so that it runs on a glib loop, at a very low level. (i.e.
instead of adding events on a custom queue, add them to the glib loop
event queue). This change should not be too invasive, and the integration
with libpurple would come for free.
I will try to write a patch this weekend, and see how hard it gets.
In any case, I would keep this completely separated from Qt!
Thanks for the feedback.
--
Ticket URL: <http://trac.qutecom.org/ticket/175#comment:11>
QuteCom <http://trac.qutecom.org>
_______________________________________________
QuteCom-dev mailing list
[email protected]
http://lists.qutecom.org/mailman/listinfo/qutecom-dev
