Re: Project hiper - High Performance libcurl
Date: Sun, 13 Nov 2005 17:07:31 +0000
Cory Nelson wrote:
> > But far more importantly, if Curl were to _require_ that the blocking
> > happens inside Curl's code, then it would be difficult to use Curl in
> > programs which already have their own event handling for other things.
> Could you elaborate why? Is this a problem specific to *nix? I don't
> see any problems for Windows.
In Windows, it's common to use threads for things like this. So there
is no problem with having one or more threads block in a library like
Curl, while the application continues processing other things in other
But in many *nix environments, it's common to avoid threads unless the
application has specific reasons for using them.
In particular, a lot of unix and unix-compatible platforms (many of
those that Curl runs on) simply don't support threads at all.
So it's unhelpful for a library to block, because it blocks the whole
You _can_ make a library that blocks while allowing the applications
to do other things, by provide hooks so that the application can
register it's own I/O handling callbacks with the library. (That's
why we mean by an event loop.)
But that's very restrictive, because you can use only one library like
that in an application, and it forces you to structure the whole
application around that library.
Which is why Curl's API is designed to have the event loop provided
by the application.
> > > Not having it in Curl would also mean we lose efficiency. By not
> > > being able to delegate which type of thread (I/O or non-I/O) to begin
> > > a request in, Curl would be forcing the user to never destroy any of
> > > the threads that Curl has touched, for fear of canceling I/O. We
> > > would no longer be able to intelligently pool threads by how heavy the
> > > workload is.
> > I don't see why you say the user couldn't cancel threads touched by
> > Curl. Surely, if the scheduler is outside Curl, the application would
> > know _exactly_ which threads Curl is using at all times?
> IOCP operations are cancelled if the thread that initiated them is
What a bizarre feature :)
Received on 2005-11-13