No Subject

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

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() )

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

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