Hi James! I think that given that we have an API for that, it should be possible to do so. But I think the special care needs to be taken to make sure that when you switch to blocking mode, there is no outstanding request that would need to be processed in the calls you are processing as it might lead to inconsistent internal state.
Reading through the ssh_channel_open() code, on the first sight it looks like this state should be able to handle the switch from non-blocking to blocking after the first return of SSH_AGAIN (assuming your code will make sure any outstanding requests will be repeated after the switch). I believe the other states are constructed in similar way so they should work in similar way, but I did not check. If you are getting the error in some reproducible (or at least semi-reproducible way), looking at a debug log what operations were happening before the error and how it actually fails would help. Ideally in the separate gitlab issue so it wont get lost on the mailing list. Thanks, Jakub On Sat, Mar 22, 2025 at 4:50 PM James Wrigley <ja...@puiterwijk.org> wrote: > > Hi there, > I nominally use LibSSH in non-blocking mode, however in some cases I want to > perform SFTP operations. Because the SFTP API does not support non-blocking > mode right now my approach is to switch the session to blocking mode, do the > SFTP operation, and then switch back to non-blocking mode. In my application > I've noticed that this can sometimes lead to sftp_new() just failing for some > reason. I haven't started debugging this properly, but my initial question is > basically, is it safe to switch a session from blocking to non-blocking mode > and back like this? Or is a session meant to be in a single mode for its > entire lifetime? > > For context I'm using LibSSH in Julia, hence the session usually needs to be > in non-blocking mode to play nicely with Julia's event loop. > > Thanks, > James
