Re: GTK - Proper Way to Code Pipes



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!





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]