Dear cURL developers,

I'm having a weird 100% CPU problem using the curl_multi_socket API and
a glib main loop (driving a GTK+ UI.) When downloading a file, no matter
how long it takes, the main loop just spams the progress callback over
and over again (downloading a 95MB file off the local network incurs 3.6
million callbacks!!) Not only is this bad of its own right, but the
callback happens so often that the UI is totally blocked while this is
going on.

The only thing that fixes it so the UI doesn't block is to lower the
priority of the glib IO watch, using g_io_watch_add_full. This way the
CPU is still pegged, but at least the UI gets priority.

I confirmed that this happens both on slow and fast network links. My
understanding is that downloading a file generally doesn't incur high
CPU usage but it can if the file is downloading very, very quickly. This
problem happens even if the file is downloading very slowly (10-15KB/s
compared to 5-6MB/s on the LAN.)

I googled around and I would assume that combining glib IO watches with
libcurl was a very common thing, and that my error would be some sort of
amateur mistake. But I haven't found anything.

I'll be working on a reduced test case and can email it to the list
sometime tomorrow. But for now, does anyone have any idea what could be
going on?

Could this have something to do with the nature of the fd, something I
could set with fcntl, perhaps?

Thanks in advance!

-- 
Joshua Kwan