On Thu, 30 Apr 2009, Jeremy Knope wrote:
> I just tried CVS with my OS X machines, this seems to fix the problem for me
> ONLY if I'm doing sleep(1) before I read. Otherwise there's risk of the
> read blocking permanently and I have to kill the application.
Well, it at least indicates that your problem is similar in nature to this
thing I just fixed.
> Any reason why this blocks but doesn't eventually return?
A blocking read that gets nothing will remain waiting until something comes
along. It will presently not time-out at all. Ever. I think we should
introduce some kind of time-out ability for them, but to be honest: I view
blocking operations as less important. But I'll gladly accept help and patches
that provide such features.
> Right now I'm using a call that reads up to 4096 bytes, calls
> libssh2_channel_read (in blocking mode) until it returns 0 bytes.
By doing this you should expect to risk hanging a long time on a read at
times.
> In my test case, I was running a command that produces 879 bytes. When it
> locked up, it was on the 2nd call to read where it would be expected to just
> return 0 but instead it's waiting for more data which none will come, or so
> I assume.
Well, if there are more data pending the hang is correct. If there's no more
data coming, the hang is wrong.
I suggest you build libssh2 debug-enabled and use libssh2_trace(handle, ~0);
to enable full tracing and when you get the problem you show us the last
~100-200 lines from that trace output. It might help.
> Is it better to use the non-blocking method maybe? This was how we were
> using it before with 0.13 with some success, but if it's better I can
> switch. 1.1 has a lot of improvements so wouldn't mind.
0.13 was eons ago so I don't consider comparisons with that very important.
Back then there was only blocking operations and somehow along the way we've
introduced a bug. We "just" need to track it down and fix it. I'm sure that's
not the only one either...
Of course you can switch to non-blocking mode as then you shouldn't have to
risk any blocks at all. But over all: bugs are expected to show up no matter
what and our job is still to find them and fix them!
-- / daniel.haxx.se ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf _______________________________________________ libssh2-devel mailing list libssh2-devel_at_lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libssh2-develReceived on 2009-05-01