On Tue, 8 Jul 2014, myriachan_at_cox.net wrote:

> I just ran into bug 1355 (CURL_POLL_REMOVE callback occurs after close call
> rather than before), and there are a couple of points I'd like to make about
> it as a counterargument to the ones made before on the bug's closure
> message.

Let me just make it clear that when people stop responding to my comments and
questions in bug reports, I mostly close them and my last comments then by
defintion becomes the closing arguments. That doesn't necessarily mean I think
I was right, but if nobody is arguing nor giving more feedback/comments on
bugs that I'm not convinced about, they're basically dead and I close such bug
reports.

> 1. If you're using Linux epoll with curl_multi, it's useful to be able to
> detach your socket from epoll before you close it.

I've not argued against the usefulness. The question is rather how important
or serious the effects of this behavior is.

> 3. Some applications, like the one in which I encountered this problem, have
> a socket loop where socket closure always happens with an empty call stack
> and only when an internal reference count hits zero. This is problematic
> when the socket is already gone.

I'm not sure I follow how this is not just assumptions on libcurl's
functionality that isn't true.

> 4. The "secondary socket" mechanism appears to bypass
> CURLOPT_CLOSESOCKETFUNCTION in Curl_closesocket in a simple inspection.

That's not true, at least not that simply put. The close socket callback is
only called for sockets that would be created by the opensocket callback,
which excludes the ones created by accept().

But you'll also not get the callbacks for sockets that are used by subsystems
or 3rd party libraries where we don't have full control or where we don't take
full control of all the socket creations/closures.

I'm not standing in the way for someone to improve this part of libcurl. I'm
just stating that the way it currently works seem consistent with the
documentation and many people seem to be able to work with that. I'm sure it
can be improved much more!

> If so, that severely limits the usefulness of that option, because it means
> that as soon as libcurl uses a secondary socket then closes it, our
> application will assert.

But there's no such "if so".

> I personally feel that certain parts of libcurl's design are flawed.

I'm sure we all have our ideas on how to improve different aspects of libcurl.
I really do my best to fix the problems I find and I plan to continue to clean
up and fix things I consider in need of fixing up.

libcurl's design is much controlled and limited by its evolutionary model: we
(virtually) never break backwards compatiblity so once added we support stuff
forever. It's hard to get everything right and its hard to have a library
created 16 years ago to grow into a perfect API and design. We have to accept
that some things have ended up a bit more bulky or inconsistent than one
would've wanted if the library would've been designed today from scratch.

We welcome all patches and help that improve libcurl!

> In my opinion, libcurl ought to have the entirety of its socket code
> factored out into a separate set of object files. All socket calls would go
> through the callback system on curl_easy_* or curl_multi_*. The socket
> implementation would merely provide the default implementation of the
> callbacks. A "socket" would merely be an intptr_t parameter to these
> callbacks. There'd be a lot more callbacks - a callback to disable Nagle,
> for example - but this'd work.

You're welcome to work on making that happen!

> This would allow the use of libcurl over things that are distinctly not
> sockets, such as Win32 named pipes.

You can basically already do that, afaik, but sure it would make it even
cleaner.

> It'd also make libcurl usable in more environments, such as where a
> BSD-compatible socket environment doesn't exist

I'm not convinced that is a good idea. Then you'd also have to use special
functions for all operations like send(), select(), recv(), poll() etc and
allowing *that* is at least one level of redirection too far for me. If you
want to support systems without BSD sockets, then write up an emulation layer
and link libcurl with that!

I'd require someone to speak up with a strong use case for that to convince
me.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html