/pidgin/main: e6c37a5e6666: New dependency: libcurl
elb at pidgin.im
Tue Oct 2 11:31:15 EDT 2012
Tomasz Wasilczyk spake unto us the following wisdom:
> 2012/10/1 Ethan Blanton <elb at pidgin.im>:
> > There are a couple of things to watch, here. First off, requiring
> > synchronous connect is bad, because it means libcurl is doing
> > synchronous DNS lookup followed by connect(), which can stall the UI.
> I'm not sure, how exactly this may lead to such conclusions. Anyway,
> I'm pretty sure, that this is just an libcurl API issue (maybe they
> didn't figred out, that somebody will need to return a new socket
> after a while).
I just looked at the curl code, and you're right, they do use async
lookups *internally*. However, it limits us to sync lookups using
their external UI. Either way, not good.
> > Can we use *real* sockets here? I assume the problem is that the open
> > socket function has to return a "real" fd in that case, and we don't
> > have one...
> That's exactly the problem.
> > Once our sockets are open, though, curl can use normal
> > read()/write()/etc. on them. That is, assuming it understands
> > SO_NONBLOCK sockets.
> I'm not sure, if I understand correctly. Are you suggesting, that we
> can return an "empty" fd and - later - swap it with real, opened
No, I don't think we can do that, but we may be able to provide an
actual socket. I was thinking out loud. I'm pretty sure we'll have
to provide a buffering abstraction to allow for curl to call open and
then write immediately, since it may think it can do that -- and even
if it doesn't *currently* think it can do that, unless their API shows
us that it never will, we'll have to buffer.
If the API actually understands a socket that's not ready, we may be
able to call socket(), save the socket someplace, call connect()
nonblocking, and hand the saved socket directly to curl. It won't be
writeable/readable/whatever until connect() succeeds or fails. I'd
have to look at the API they offer to see how reasonable this is.
> > (..*) this can go into 3.0.0 without problem. We haven't
> > frozen that API.
> I meant the situation, in which we figure out, that some new feature
> is useful *after* releasing 3.0.0.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 482 bytes
Desc: Digital signature
More information about the Devel