On Sun, 20 Sep 2009, Peter Stuge 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.
How would it accomplish that? Please expemplify by taking an existing
nasty-looking function and convert it to the way you claim it could work. I
just don't see how this would work in a way that differ much from what we
already have.
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.
That would of course lead to a whole lot more select() calls since we'd have
to return after every send() and recv(). And it wouldn't save us from all the
state-keeping logic, as it'd still be state-machine code all over. Possibly
it'd be slightly cleaner internal code though but it would also require a
more or less complete rewrite of most code - something we avoided this far by
doing the non-blocking code the way it is currently done.
We also need to minimize the amount of select() calls, as it is a very
expensive function when the amount of file descriptors increases. And if the
application uses an event-based lib like libevent or libev it would rather
only have to call libssh2 on socket events.
(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!
I already quoted a man page sentense saying exactly this. For Linux. I'm sure
we could come up with more cases for more platforms if we really wanted to.
I DEMAND a non-blocking libssh2 API.
That's fine of course. You didn't say why
I did say libcurl requires it, and libcurl is a pretty big user of libssh2.
Most of the commercial users of libssh2 that I know of use it with libcurl, as
libcurl is a rather fancy abstraction layer to do multiple file transfer
protocols including SCP and SFTP.
Also, a non-blocking API is of course useful for all the reasons select() +
non-blocking operations is good in general: to be able to do many transfers at
the same time.
Not to mention that similiar libs (OpenSSL, GnuTLS, NSS etc) all offer
non-blocking APIs so without a such libssh2 would stand out as an oddball in
the family.
a true non-blocking API
Can easily be had also when select() is reliable for blocking sockets.
With the caveats we've discussed, yes, which doesn't make it "easily" in my
mind.
--
/ daniel.haxx.se
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
