Multi-threaded access to "purple_normalize" issue ?

[Daniel Atallah]

2008/1/15 Mauro Sérgio Ferreira Brasil <mauro.brasil at tqi.com.br>:

>  Hello there!
>
> I work with an application that uses libpurple as infrastructure for IM
> services, and very rarely I'm questioned by our customer about problems
> their client have while sending messages.
> They claim that sometimes they send a message to one person but it goes to
> a different one.
>
> Considering that our client's application work with two different threads
> (application UI thread, and libpurple - or glib - one), we are facing a very
> difficult problem to track here.
>
> All access to libpurple is already being "sincronized" (through
> "purple_timeout_add" and other methods), but we put only the final methods
> like "purple_account_set_status", "purple_conv_im_send", etc, inside the
> "serialized" scope. While lots of libpurple methods  like
> "purple_conversation_new", "purple_utf8_try_convert", "purple_normalize",
> etc, are accessed outside the "serialized" scope.
>
> After the first analysis, we found one method that is making us a little
> bit worried considering the multi-thread scenario we have here, that is
> "purple_normalize". This method documentation states that the returning
> value is a pointer to a static variable and should not be stored for
> long-term usage. But, the question is: Could it be stored at all ?
>
> In most of places the result of this method is automatically duplicated
> (through "g_strdup" method), or used immediately on a comparing method, but
> is still there methods that stores the returned value on variables to short
> or very short term usage.
> Inside the MSN protocol implementation, the result of method
> "msn_normalize" being stored for further use is even more common.
>
> Considering our situation here, of multiple threads accessing the
> libpurple API while using this method, does any one know whether this could
> lead to problems ?
>

Yes, it certainly could lead to problems; you need to synchronize access to
the purple_normalize function.

I can't speak for the other functions you've mentioned, but as a rule,
unless you have researched a particular function in detail to make sure that
it is safe to do so, you shouldn't be accessing it from several threads.
Any function that can be used safely in this manner will be thread safe by
coincidence, not by design; as such, the function may change in the future
so that it is no longer safe to use from multiple threads.

It would be much safer to access all of libpurple from a single thread.

-D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20080115/6de3ad24/attachment.html>