On Thu, 21 Jul 2005 00:18:58 -0400, Christopher Subich <[EMAIL PROTECTED]> wrote: >Peter Hansen wrote: >> stringy wrote: >> >>> I have a program that shows a 3d representation of a cell, depending on >>> some data that it receives from some C++. It runs with wx.timer(500), >>> and on wx.EVT_TIMER, it updates the the data, and receives it over the >>> socket. >> >> >> It's generally inappropriate to have a GUI program do network >> communications in the main GUI thread. You should create a worker >> thread and communicate with it using Queues and possibly the >> AddPendingEvent() or PostEvent() methods in wx. There should be many >> easily accessible examples of how to do such things. Post again if you >> need help finding them. > >I'd argue that point; it's certainly inappropriate to do >(long-)/blocking/ network communications in a main GUI thread, but >that's just the same as any blocking IO. If the main thread is blocked >on IO, it can't respond to the user which is Bad. > >However, instead of building threads (possibly needlessly) and dealing >with synchronization issues, I'd argue that the solution is to use a >nonblocking network IO package that integrates with the GUI event loop. > Something like Twisted is perfect for this task, although it might >involve a significant application restructuring for the grandparent poster. > >Since blocking network IO is generally slow, this should help the >grandparent poster -- I am presuming that "the program updating itself" >is an IO-bound, rather than processor-bound process.
In the particular case of wxWidgets, it turns out that the *GUI* blocks for long periods of time, preventing the *network* from getting attention. But I agree with your position for other toolkits, such as Gtk, Qt, or Tk. Jp -- http://mail.python.org/mailman/listinfo/python-list