Where is select() being run from? Is it from within the GTK+ main loop or from somewhere in your application or in another library? I think GTK+ uses poll() to listen for input... which may be implemented with select()... but all the same... if it's the select() call that GTK+ is running then there must be something weird going on. If you are calling select(), then GTK+ will be unresponsive... because it cannot respond to input if a callback is sitting in a blocking function. If this is your problem (you're running select() and not allowing GTK+ to run select()/poll() for you) then you may want to see if there's a way to hand your file descriptors over to the main GTK+ for listening. I don't think there's a way to make select() listen for mouse events. - Anna On Fri, Apr 28, 2006 at 08:38:59AM -0400, Derek Piper wrote: > > Hi, > > No, it's not a basic networking thing. I've written socket programs > before. :) The program itself isn't freezing, that's what I was saying > I've been able to determine. It's just waiting normally in select (for > network packets) whenever I get a 'hang' dump grab for windbg. So, > that's not of any help to track down the problem. Thinking it was > something with select() under windows, I set the timeout to zero and > then called 'Sleep()' manually to test it. Sure enough, whenever it's > 'grabbed' the program is sleeping which makes sense as it's not really > hung and that's where a lot of programs will be if you were to take a > snapshot of them. > The program is still operating, I get debugging printfs through my > main loop and also it is still reading from the network and recording to > disk. The ONLY thing that appears to hang is the GTK part. Windows just > says it's window is 'unresponsive'. > So, it's along the GTK lines I was seeking some advice. > > Derek > > Anna wrote: > >On Thu, Apr 27, 2006 at 01:56:24PM -0400, Derek Piper wrote: > > > >> Hi, > >> > >> I have a strange bug I'm trying to track down. I've been able to > >>determine that the program is not hanging in itself, it's the window > >>that just 'freezes'. > >> The program I have has a 'telnet' mode, and I am able to telnet to > >> the program even when the GTK window has 'hung'. When I enter a > >> command, the window 'unfreezes'. > >> This is using GLib 2.10.1 and GTK 2.8.17 DLLs run from a > >> 'standalone' environment, i.e. PATH set to include the relevant DLLs > >> etc. The error still occurs using GTK 2.8.9 (the latest Windows > >>installer) and also on GTK 2.6.10 (Windows). > >> Has anyone else had that sort of thing happen or have any idea as to > >>why it's happening? Trying to get a 'hang' dump of my program only > >>reveals it's waiting in the select(), or in a sleep. My program was > >>originally written without an interface (apart from telnet) but I added > >>the GTK interface and call this code in a function: > > > > > >what's the select() waiting for? are you just using it to sleep? I > >don't understand your comment about "or in a sleep". If your program is > >hanging and you discover it's just sitting in a sleep() too long, why > >not just adjust the amount of time it's sleep()ing for? and, the > >select() call should return when whatever it's wainting for arives. You > >can give select() a timeout. why not do that? have you tried running > >it under a debugger? the fact that it runs fine on Debian but hangs on > >windows says "timing issue" to me. things are probably running in a > >slightly different order in Windows than in Linux, causing... something > >like... a file descriptor to be in a writable state while you're still > >waiting for readable. good luck. > > > >- Anna > > > > > > -- > Derek Piper - dcpiper@xxxxxxxxxxx - (812) 856 0111 > IRI 323, School of Informatics > Indiana University, Bloomington, Indiana _______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
