No Subject

[James Bailie <jbailie wwdc com>]

In message <19990111192615.A2779@storm.local>, Andreas Bombe writes:
>On Sat, Jan 09, 1999 at 04:48:27PM -0500, Mike Lindahl wrote:
>> I am writing a program for a CS class and we were given a socket source
>> file to work with.  It opens a socket and would normally be used for
>> terminal applications (it is extra credit to be using GTK).  Thus, since
>> it should be used for terminal, it blocks.  I don't think they would like
>> it very much if I rewrote the network interface (and I don't know if I
>> would be able to do it).  Now, the problem is that when I click on a
>> button in GTK, the program goes into receive mode, so it is in an infinite
>> loop as it is blocking.
>[...] 
>> Is there an easy way to solve the entire networking problem using
>> signal-based sockets that is relatively easy to implement (either using
>> GTK or some other thing, such as SIGIO) that anyone knows of??
>
>If you use select() to block on the socket, you can tell GTK+ to do the
>select so that it effectively doesn't block the entire application
>(look it up in the header files somewhere, don't know the exact call
>from the top of my head).
>
>You could also use SIGIO. Or you could use (POSIX) threads or separate
>processes.

If your program isn't doing much while waiting for data, say you just want
to keep the interface from blanking, or perhaps check for the pressing of a
cancel button, you can use select() with a timeout and do 

while( gtk_events_pending() )
   gtk_main_iteration();

at every timeout. I have used this technique successfully.

Or if you want your program to resume processing, you can use
gdk_input_add() and go on your merry way letting the toolkit call one of
your callbacks when the appropriate descriptor becomes readable.


- - --
James Bailie

http://www.wwdc.com/~jbailie