On Tue, 2004-06-22 at 19:27, dave wrote: > I personally believe the best way is to have a socket or pipe as a > trigger, and do all your gui stuff in one main thread, triggered by a > socket connection. Immunity does this on both win32 and linux to avoid > all the problems with threading entirely. If I get some time, I'll write > a quick paper on it and give some good examples. > > -dave
I agree with Dave. I have used pipes and have just added the incoming data to in an internal queue and have a work proc or timeout handler get the data out of the queue and do the GTK work on it. > > > Prash wrote: > > >Ok. What I'm trying to do here is use python "thread" module and am not > >using threading in pygtk. My aim is to start a new thread every 30 > >seconds, fetch news and display in the textview. > > > >So I write > >-------------------------- > >import thread > > > >vlock = thread.allocate_lock() > >newsfeedtimer=gtk.timeout_add(30000, startnewthread, dispnewsfeeds) > > > >def startnewthread(func) > > mythread = thread.start_new_thread(func, ()) > > return gtk.TRUE > > > > > >def dispnewsfeeds(): > > global vlock > > # Instantiate the newsfeed class and execute its disp method > > vlock.acquire() > > news = newsfeedclass() > > news.disp(textview) > > vlock.release() > >----------------------------- > > > > > >Note that I'm not using > >gtk_threads_init/gtk_threads_enter/gtk_threads_leave anywhere. Now is > >this supposed to work or am i way off target here? > > > > > > > > > >On Tue, 2004-06-22 at 15:38, Christian Robottom Reis wrote: > > > > > >>On Tue, Jun 22, 2004 at 08:14:22AM +0100, Prash wrote: > >> > >> > >>>I started out to code threading but when I finished and ran it - I > >>>realized that redhat had compiled pygtk without threading support > >>>(another one of their "atrocities"). I opted for laziness and explored > >>>generators but I realized I had already coded the algorithm to call many > >>>functions and generators didn't make any sense in this case. > >>> > >>> > >>Generators won't *always* solve the problem; for instance, when using > >>any sort of blocking call into a C extension, nothing apart from threads > >>is going to allow the mainloop to run concurrently anyway. > >> > >>Generators are more coarse-grained than threads, in general, since you > >>choose at which points you want to yield control. That's intentional. > >> > >> > >> > >>>Take the example: I have to call a function to display newsfeed every > >>>hour - so I add a timer event. Now that newsfeed function instantiates > >>>another class and calls its function to fetch and display data in a > >>>textview. Now to call that function in a timeout_add again and adding > >>>generator support didn't appeal to me at all. > >>> > >>>So I'm adding gtk.main_iteration() and hoping it would work smoothly. > >>> > >>> > >>If you have the option to insert this in your code, it's an alternative > >>(though IMO it usually violates cohesion IMHO since you have UI code in > >>your application-specific bits). It has the same coarse-grained > >>semantics that generators do, however. > >> > >>Take care, > >>-- > >>Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 > >> > >> > > > >_______________________________________________ > >pygtk mailing list [EMAIL PROTECTED] > >http://www.daa.com.au/mailman/listinfo/pygtk > >Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/ > > > > > > > _______________________________________________ > pygtk mailing list [EMAIL PROTECTED] > http://www.daa.com.au/mailman/listinfo/pygtk > Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/ -- Steve McClure <[EMAIL PROTECTED]> _______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
