>> Based on suggestions from this mailing list I've implemented a pipe to >> pass data from my other processes to the main GTK thread. I noticed >> that when writing to the pipe there was a long delay before it was >> handled. I'm assuming this is because it was a pending event. >> >> Can someone please let me know if my code to "fix" this (for lack of a >> better word) is correct? The code solves my issue and the pipe is read >> immediately, I'm not sure if it is the proper way to do it. >> >> [code] >> ... main processing ... >> >> written = write(status_pipe[1], &var, strlen(var)); >> gtk_main_iteration(); >> >> ... continue processing ... >> [/code] >> >> Is there a better way to do this? Thanks for any input. > >Um, yes I'd say. > >Maybe its just my personal opinion but I always prefer letting the main >loop do its thing and not hack around it by adding: > "while (events_pending) iteration_do();" >sprinkles here and there, I think its important to write your code in >short callbacks and return to the main loop as much as possible.
I felt the same way, which is the main reason I posted to the list. I'm fairly new to GTK especially when it comes to complex issues like this. >Pipes are pipes, in glib or otherwise you need an understanding of how >they work in order to give a precise forecast of what your program will >do. > >Pipes block, for instance if you open a pipe for writing it will block >until a reader has opened the other end, writing to the pipe will block >until the reader reads the written bytes. I'm pretty sure this is exactly what I've been seeing. Within my app I have a 'clicked' event attached to a button which basically starts all of my processing. Within this callback I call my main C++ routine which creates my objects and starts doing work. My app is multi- threaded but I had such a headache trying with the threads_enter/leave and someone suggested using pipes and use g_io_add_watch to "watch" a pipe. Within one of my C++ routines I write to the pipe, but the "watch" routine does not get called during execution of my threads. When control is given back to the GUI thread (hence my call to gtk_main_iteration()) then the "watch" routine gets fired off. I wanted to use the "watch" routine to move my progressbar and update the statusbar in my application and I'm having such a hard time getting it working with my threads. >typically people will open (pipename, O_WRONLY | O_NONBLOCK) just to >open the file with out blocking, and then fcntl(fd...) to set it back >to blocking mode... then you might go ahead and select() the fd to know >if the pipe is ready to receive one byte of data without blocking >(maybe select()/write()ing one byte at a time until the buffer to write >is finished... always returning to the main loop when it would block). I'm doing this as well. I basically followed the following example: http://wwwtcs.inf.tu-dresden.de/~tews/Gtk/catch_signals.c >Remember that this heavily depends on what you are going to do with >the pipe, do you want the reader to block in read() all the time ? >do you want the writer to block in write() and have the reader >test for a readable condition on the file descriptor before reading >a byte ? do you want to use nonblocking read/write operations on both >ends and just buffer the data in the pipe ? it can get complex. > >Cheers, > -Tristan I really would like to be able to write to the pipe from my threads, have the GUI read from the pipe and then update my progress/status bars based on the data within the pipe. If anyone has any suggestions I would greatly appreciate it. I thought I was on the road to success but now I'm starting to doubt myself. Thanks. ________________________________________________________________________ Try Juno Platinum for Free! Then, only $9.95/month! Unlimited Internet Access with 1GB of Email Storage. Visit http://www.juno.com/value to sign up today! _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
