On Thu, 17 Jun 2010, Peter Stuge wrote:
> This shows a bug. Looking at the code agrees. One could argue this is
> a bug in the example but I really hate that libssh2 insists on the
> IMO useless non-blocking approach in every single instance
Ok, so here we go again. I'll bite.
libssh2 does not insist on a non-blocking approach. It provides both blocking
and non-blocking functionality. How can you claim otherwise? Yes there are
bugs like this one, but they are but mistakes and not actual design flaws.
The main problem with the blocking interface is when using multiple channels
as mentioned before, but my suggested approach will solve that issue as well
and once that is corrected I know of no flaws in the blocking mode. Do you?
(And this flaw can in fact already be worked around by the use of
libssh2_poll_channel_read() but I'm not too happy with this polling kind of
solution)
> Anyway, documentation and code for libssh2_agent_userauth() disagrees, and
> the code is returning -37 or LIBSSH2_ERROR_EAGAIN from the lower layers of
> libssh2, which means that the caller should just try again, but the example
> interprets this as failure which is also what the man page indicates.
That should not happen when the blocking API is used, so yes it is a true
libssh2 bug.
> I do not want to have agent ops be non-blocking, but on the other hand I
> want none of libssh2 to be non-blocking. While this gets discussed further
> you could try the attached patch, Thomas.
The patch is in the right ballpark but will of course busy-loop far too much.
It should actually use the BLOCK_ADJUST() macro.
-- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-develReceived on 2010-06-17