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
