Re: [libssh2] EINTR treatment at session.c/ _libssh2_wait_socket()

On 30/04/12 10:31, Nick Rudnick wrote:
> Dear all,
>
> thanks to your help I was able to find a workaround for my problem,
> being in relation to Haskell and maybe other languages emitting signals
> that may interfere libssh2 processing (info thanks to Edward Z. Yang):
>
> http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Signals
>
> This problem seems to be solved by a very small modification (diff file
> is attached):
>
> 663,664c663,666
> < session->err_code = LIBSSH2_ERROR_TIMEOUT;
> < return LIBSSH2_ERROR_TIMEOUT;
> ---
> > if(errno != EINTR){
> > session->err_code = LIBSSH2_ERROR_TIMEOUT;
> > return LIBSSH2_ERROR_TIMEOUT;
> > }
>
> Pondering the operational semantics of _libssh2_wait_socket() now, with
> the impression that an EINTR usually would be regarded as a transient
> incident, I am asking myself in how far not aborting at EINTR might
> violate the intended behavior in any way.
>
> If there were no objections, an introduction to the code base would be
> great – especially on Windows, where a necessity to compile often means
> a considerable amount of effort.

The above would cause BLOCK_ADJUST to automatically go around when
interrupted. This would make it impossible, for example, to allow a user
to interrupt a long running process with Ctrl-C if the API was in
blocking mode.

Unfortunately, all uses of IO operations must be wrapped in checks which
include a test for EINTR. This allows you to do this:

int cancelled = 0;

void signal_handler() {
   cancelled = 1;
}

do {
   rc = libssh2_channel_read();
} while (!rc || (rc == LIBSSH2_ERROR_TIMEOUT && !cancelled));

There should be a different return code for EINTR, though.

Matt

-- 
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel