using publish and subcribe between threads
Hi all,
I’m curious to know whether or not the wxpython pub/sub system is thread safe - I want to have a worker thread publish something so my gui components can they can respond appropriately to a status change. Assiming that pub sub is not thread safe, I’m planning to use a wx.CallAfter function to trigger the Publiser.sendMessage call but would like to know if this is necessary.
Thank you
Dominic
Hello,
On Mon, Apr 27, 2009 at 8:41 AM, Barraclough, Dominic (ext. 414) <djb@qvii.com> wrote:
Hi all,
I'm curious to know whether or not the wxpython pub/sub system is thread
safe - I want to have a worker thread publish something so my gui components
can they can respond appropriately to a status change. Assiming that pub sub
is not thread safe, I'm planning to use a wx.CallAfter function to trigger
the Publiser.sendMessage call but would like to know if this is necessary.
No pubsub is not threadsafe. Its calls are direct blocking calls made
on the same thread as they were invoked from. So CallAfter or another
mechanism would be necessary when modifying gui components.
Cody
Hi Dominic,
Hi all,
I'm curious to know whether or not the wxpython pub/sub system is thread safe - I want to have a worker thread publish something so my gui components can they can respond appropriately to a status change. Assiming that pub sub is not thread safe, I'm planning to use a wx.CallAfter function to trigger the Publiser.sendMessage call but would like to know if this is necessary.
Thank you
Dominic
Unfortunately, pubsub is not threadsafe. Instead, use wx.CallAfter or wx.CallLater along with the pubsub call.
Pubsub has no way of knowing that a subscriber is operating in a different thread from the sender. What you are facing is not an issue of thread safety of the library (which is the characteristic that a library’s components – functions, class instances etc – remain valid even if used simultaneously from more than one thread) but rather: 1. which threads are allowed to update the GUI, and B. transfer of data from one thread to another. As you know the answer to A is “only the main thread”. This is what leads to B: your worker must transfer data to main thread. There are many ways this can be done and it is not pubsub’s job to impose this (synchronized queues, wx.CallAfter, wx.lib.DelayedResult, thread events etc). The easiest is wx.CallAfter.
However I have also used the following design in a “highly” parallel application (where there could be 20 worker threads running – NOT for efficiency but for monitoring various OS changes occurring in parallel): all threads communicate with main thread via Queue, and main thread reads Queue and translates into pubsub messages. This was necessary because I didn’t want the worker threads to depend on wx, so calling wx.CallAfter was not an option.
About thread safety: I have used pubsub in an app with several threads without problem but this is not proof just evidence that certain pubsub versions may possibly be thread-safe in certain circumstances 
Oliver
On Mon, Apr 27, 2009 at 9:41 AM, Barraclough, Dominic (ext. 414) djb@qvii.com wrote:
Hi all,
I’m curious to know whether or not the wxpython pub/sub system is thread safe - I want to have a worker thread publish something so my gui components can they can respond appropriately to a status change. Assiming that pub sub is not thread safe, I’m planning to use a wx.CallAfter function to trigger the Publiser.sendMessage call but would like to know if this is necessary.
Thank you
Dominic
wxpython-users mailing list