Havoc Pennington wrote: > Yes, it's normal. If you ask to have your callback invoked whenever > the fd is ready for writing, and it's always ready, then your callback > will be invoked continuously eating 100% CPU. That doesn't seem so > surprising - you get what you ask for. ;-) Yep. Once understood it's easy :-)
> GLib can't read your mind and only call the callback when you actually > have something to write! Nope. But I thought it was called in a cycle, so other events could get attention. > Normally people only add an IO_OUT callback when they have stuff to > write, then they remove the callback when they no longer have a write > pending. Well, having to monitor an external library's activity on a socket it wasn't so obvious. > The reason it blocks widget redraw is that widget redraw only happens > in an idle handler (when there's nothing else to do). Understood. Tks! What I still can't understand is HOW IN THE H..L the multithreaded version could completly block mouse activity even out of the program window when I did a gtk_widget_set sensitive() on a ctree :-( Just it! If I removed the set_sensitive it all worked... Bahf! Now it's been rewritten for NOT use threads and it works... I hope :-) Woops... Is it always safe to call gtk_main_iteration_do(FALSE) ? Seems not - from the GIOChannel callback , at least... since if it's continuously called it becomes infinite recursion. Any other callback I must watch for ? Tks, Diego. _______________________________________________ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
