/pidgin/main: e6c37a5e6666: New dependency: libcurl

Tomasz Wasilczyk tomkiewicz.groups at gmail.com
Tue Oct 2 04:26:48 EDT 2012

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).

> 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

> (..*) 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.


More information about the Devel mailing list