On Tue, Feb 23, 2010 at 11:39:39AM -0800, Danek Duvall wrote: > [email protected] wrote: > > > http://cr.opensolaris.org/~johansen/webrev-14683/ > > Is there a particular reason that you reset private variables in shutdown() > differently than you do in reset()?
The rationale is that in reset() the engine is going to be used again, but in shutdown() the engine finished. In that case, I'm trying to clean up as many of the objects that might hold a lot of memory, since I don't explicitly control when the caller drops the final reference to the engine object itself. > If there's no way to distinguish these particular pycurl.error instances > from other things that go wrong in remove_handle(), is there a missing > pycurl (or libcurl) interface? What are potential symptoms of such a > thing? Leaking file descriptors? Worse? > > Looks fine, though, if that's what you've got to work with. Sadly for us, this appears to be all that we can currently get from Pycurl. It has one class for execeptions, pycurl.error, that is used for any error the library encounters. If we were going to enhance Pycurl, changing the way the exceptions are generated by the C module would be a priority. Hypothetically, anyway, the remove_handle() could return these errors: "cannot add/remove handle - multi-stack is closed" - tried to remove a handle from a multi object that had .close() called on it already. "cannot add/remove handle - multi_perform() already running" - tried to remove a handle while another thread is calling multi.perform() "cannot add/remove handle - perform() of curl object already running" - Doesn't make sense in this context, but I presume this happens when one thread tried to call multi.add_handle() while another thread has called easy.perform() on the handle that is to be added. "cannot add/remove handle - curl object already on another multi-stack" - Doesn't make sense in this context. Happens when object added to a 2nd multi stack while already on one. "curl object not on this multi-stack" - This is the one we hit. Tried to remove a handle that isn't present. "curl_multi_remove_handle() failed due to internal errors" - Generic unknown internal error case. In regard to your question about the consequences of treating all of these errors the same, the only time this happens is in the cleanup path. Most of these errors aren't fatal to cleaning up, as they indicate that the handle was already removed, or the multi handle isn't in a valid state. If multiple threads are accessing the multi handle at the same time, we'll get these exceptions from other parts of the code too. I don't think we'll leak anything, since the easy handles get cleaned up and reset even if the remove returns an error now. If you think we should actually compare the error string, we could do that, but it seemed a bit gross. Thanks for looking at this, -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
