Daniel Stenberg <[EMAIL PROTECTED]> writes:
> On Fri, 26 Jan 2007, Simon Josefsson wrote:
>
>>> libssh2_sftp_read() might need attention anyway since it is documented to
>>> return -1 on error which is hard to do on unsigned variables, and because
>>> the normal read() returns ssize_t and I thin
On Fri, 26 Jan 2007, Simon Josefsson wrote:
>> libssh2_sftp_read() might need attention anyway since it is documented to
>> return -1 on error which is hard to do on unsigned variables, and because
>> the normal read() returns ssize_t and I think this should mimic that.
>
> Yup, that sounds simp
Daniel Stenberg <[EMAIL PROTECTED]> writes:
> On Fri, 26 Jan 2007, Daniel Stenberg wrote:
>
>> I think I like this idea. It would also make it clearly which functions that
>> would work non-blocking since we'd only implement those that truly are...
>
> Ok, let's say I take that approach for funct
On Fri, 26 Jan 2007, Daniel Stenberg wrote:
> I think I like this idea. It would also make it clearly which functions that
> would work non-blocking since we'd only implement those that truly are...
Ok, let's say I take that approach for functions that currently return
pointers and not just ret
On Fri, 26 Jan 2007, Simon Josefsson wrote:
> You could write a non-blocking version of those functions and calling
> them:
>
> int libssh2_async_sftp_init(..., LIBSSH2_SFTP **sftp)
> int libssh2_async_sftp_open(..., LIBSSH2_SFTP_HANDLE *sftph)
[...]
> Of course, change the names to something mo
On Fri, 2007-01-26 at 12:40 +0100, Daniel Stenberg wrote:
> 2 - for LOTS of functions we need to change the prototypes to allow them to
> return a "EAGAIN" error code (instead of blocking) until they are done
> and
> can return ok. A few examples are libssh2_sftp_init(),
> libssh2_s
Hello
I've written two example programs that do SCP and SFTP downloads in a
non-blocking manner, and both of the now run fine here.
There's a few BUTs to this claim, and I'd like to share them with you:
1 - not all functions are or will be non-blocking, as there is a vast amount
of them an
On Thu, 4 Jan 2007, Jens Alfke wrote:
> That doesn't sound right. Blocking I/O shouldn't consume any more CPU than
> non-blocking. If the worker thread is blocked waiting for data to arrive (or
> be sent), it should be inside a system call, probably read(), consuming no
> CPU.
The code has pos
>> I have written new versions of the transport layer functions
>> libssh2_packet_read() and libssh2_packet_write() that both
>> should work with non-blocking sockets and they return a specific
>> error code instead of blocking.
>>
>> I've verified that the ssh2_sample program still works with
On 4 Jan '07, at 3:33 PM, Greg Hulands wrote:
I would like to help out on this effort as I write a open source
connection framework for Mac OS X that uses libssh2 for the sftp
transfers. We have the problem that it pegs our worker thread to 100%
of the cpu when using sftp.
That doesn't sound
On Fri, 5 Jan 2007, Greg Hulands wrote:
> I was just wondering what the status of the non blocking effort is?
I have written new versions of the transport layer functions
libssh2_packet_read() and libssh2_packet_write() that both should work with
non-blocking sockets and they return a specific
Hi,
I was just wondering what the status of the non blocking effort is?
I would like to help out on this effort as I write a open source
connection framework for Mac OS X that uses libssh2 for the sftp
transfers. We have the problem that it pegs our worker thread to 100%
of the cpu when usin
12 matches
Mail list logo
