Regis wrote:
> after applying patch [1] I could pass HttpsURLConnectionTest. I'm not
> sure whether it's the best way to resolve this, and I think we need to
> find out a way that classlib can work with both drlvm and IBM vme
> painless.
Yes, I assume that the refactored socket code opened up a timing window
in this test case that was always there, since I don't recall that we
did this retry in M8 and earlier?
> I'm familiar with signals handling, is it possible to define
> some macros to deal with the signals and retry system calls, and we can
> add build options to select turn it on or off?
>
> [1]
>
> Index: modules/luni/src/main/native/luni/unix/OSNetworkSystemLinux.c
> =====================================================================
> --- modules/luni/src/main/native/luni/unix/OSNetworkSystemLinux.c
> +++ modules/luni/src/main/native/luni/unix/OSNetworkSystemLinux.c
> @@ -71,15 +71,20 @@ selectRead
> my_pollfd.fd = hysocketP->sock;
> my_pollfd.events = POLLIN | POLLPRI;
> my_pollfd.revents = 0;
> - result = poll (&my_pollfd, 1, timeout);
> -
> - if (result == 0)
> - return HYPORT_ERROR_SOCKET_TIMEOUT;
>
> - if (result == -1)
> - return HYPORT_ERROR_SOCKET_OPFAILED;
> + while (1) {
> + result = poll (&my_pollfd, 1, timeout);
> + if (result == 0)
> + return HYPORT_ERROR_SOCKET_TIMEOUT;
>
> - return result;
> + if (result == -1 && errno == EINTR) {
Hmm, so how do we know that the EINTR was caused by the SIGUSR2 signal?
Isn't this too broad a condition in which to 'continue'?
...and when we do continue we will wait for the full timeout period
again. That doesn't seem right either.
It may be a pragmatic fix to get us through to M9, but it looks like an
area that requires a more thorough consideration.
Regards,
Tim
> + continue;
> + }
> + if (result == -1)
> + return HYPORT_ERROR_SOCKET_OPFAILED;
> +
> + return result;
> + }
> }
>
>
