cURL / Mailing Lists / curl-users / Single Mail

curl-users

Re: [LIBSSH2_ERROR_EAGAIN problem] proposed patch for curl/libssh2 bugfix

From: Vlad Grachov <fmot.fics_at_gmail.com>
Date: Wed, 1 Oct 2008 19:25:21 +0900

I'm sorry for posting the same again to a different list.I just didn't see
your reply to my letter in the library list so I thought you missed it or
something.
I changed my patch files a little bit:
1. libssh2.h header contains a new define
HAVE_LIBSSH2_SESSION_BLOCK_DIRECTION
2. Added a man page for a new function in libssh2
3. Function is now named libssh2_session_block_directions; constant names
are changed a bit as well
4. Inbound and outbound constants are now 0x01 and 0x02 to be used in the
binary mask
5. libcurl's ssh.c #ifdefs HAVE_LIBSSH2_SESSION_BLOCK_DIRECTION

It seems in case of multi interface the patch causes a wrong behavior. The
wait (select) should be done on a number of sockets in one place.
But my patch calls select inside ssh_statemach_act. I think I may need some
help here.
The patch works well for easy interface but will cause lags if used in multi
interface.

Best regards. Vlad.

On Mon, Sep 29, 2008 at 8:28 PM, Daniel Stenberg <daniel_at_haxx.se> wrote:

> On Mon, 29 Sep 2008, Vlad Grachov wrote:
>
> Thanks! But I do have a few comments on this:
>
> First, please give us at least a week to respond until you resend the same
> stuff. You can check http://curl.haxx.se/lxr/source/TODO-RELEASE to figure
> out if your issue is added for pending "action".
>
> Then, you post libcurl stuff to the users list which we generally
> discourage since you cut out the vast majority of libcurl hackers that hang
> out on the correct list: curl-library
>
> Thirdly, your patch to libssh2 should be posted to the libssh2 list for
> consideration for that project. I would also suggest that you add a man page
> for the new function, to make it easier to the libssh2 crowd to understand
> the function and how to use it.
>
> The problem is related to libssh2 as well because LIBSSH2_ERROR_EAGAIN
>> return code does not provide any information about the cause of would-block.
>> Regardless of whether recv() or send() returned EAGAIN all the information
>> curl can get from libssh2 is the one and same LIBSSH2_ERROR_EAGAIN error
>> code.
>>
>> The proposed 2 patches are a patch to libssh2 and a patch to curl. They
>> modify the libraries in a minor way.
>>
>
> Since this libcurl patch makes libcurl depend on this change in libssh2 it
> would also make sense to do a "best effort" for the cases where the libssh2
> is not up-to-date with this. That is, #ifdefed on
> HAVE_LIBSSH2_SESSION_BLOCK_DIRECTION.
>
> But also, I would rather change the libssh2 function's meaning to instead
> be "I want you to wait for these actions on the socket before you call the
> libssh2 function again" since that would then allow libssh2 to actually wait
> for multiple actions without the API having to be changed again. The
> function would then return 1 or 2 bits set in a bitmask.
>
> The libcurl part of the patch would then also need to be modified
> accordingly.
>
> The patched curl no longer waste CPU when the socket would block. Tested
>> under Linux and Windows.
>>
>
> That's indeed very nice to see!
>
> --
>
> / daniel.haxx.se
> -------------------------------------------------------------------
> List admin: http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-users
> FAQ: http://curl.haxx.se/docs/faq.html
> Etiquette: http://curl.haxx.se/mail/etiquette.html
>

-------------------------------------------------------------------
List admin: http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-users
FAQ: http://curl.haxx.se/docs/faq.html
Etiquette: http://curl.haxx.se/mail/etiquette.html

Received on 2008-10-01