Daniel Stenberg wrote:
> You could also just reverse the question: with select(), blocking
> sockets and recv() and send() that will return on short reads and
> writes, why bother to have the socket blocking?

I think it would lead to an API with a simpler and more efficient
implementation without any drawbacks except effort required, so it
could be a good mid- to long-term goal.


> make it non-blocking in nature without using non-blocking sockets
> is really tricky

Hm, I don't think I agree here.


> With blocking sockets we can never do recv() or send() without a
> preceeding select() or poll()

The way I see it would work is for the calling app to take care of
select()ing, and only calling into the library when there is
something to do.


> (and yet there is the odd chances they can still block due to
> kernel-details).

I would love to hear about your experience in more detail! Which
systems, how often, archived upstream discussion, etc. This is so I
can understand the kernel-side problem better (because like Heiner I
am convinced it is a bug), so I can learn where I cannot rely on
select() anymore as I might have before, and so I can find out how
the upstream people were reasoning about this.


> So what I come back to over and over again in this discussion:
>
> I DEMAND a non-blocking libssh2 API.

That's fine of course. You didn't say why, but I assume it is what
fits libcurl. I agree it is important to have libssh2 continue to
work well for you.


> a true non-blocking API

Can easily be had also when select() is reliable for blocking
sockets.


> it is a lot easier and less messy by setting the actual 
> underlying socket to non-blocking to never risk that it blocks.

We disagree on this, but that's fine too.


> If someone thinks I'm wrong at any of these points, it's perfectly
> fine and all, but until someone brings code that proves they can
> offer a non-blocking API with blocking underlying sockets and still
> have the internal code look decent it's only talk and talk is
> really lightweight against working code.

Yes indeed! Now there's working code again, but I would still like to
have a go at blocking mode at some point, now that I understand the
motivation for non-blocking mode. I wanted some discussion because I
didn't know the background. Thanks for clearing it all up! :)


//Peter
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel

Reply via email to