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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libssh2-devel
