Re: Switching between blocking and non-blocking mode

[Jakub Jelen <jjelen@xxxxxxxxxx>]

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 <james@xxxxxxxxxxxxxx> 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