Re: g_io_add_watch can block redraw ?

[Diego Zuccato <diego otello alma unibo it>]

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.