Tim Ellison wrote:
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
Sorry here should be *not* familiar....
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.
Yes, the patch need to be refined, I'm still learning how to write
signal handler :)
Regards,
Tim
+ continue;
+ }
+ if (result == -1)
+ return HYPORT_ERROR_SOCKET_OPFAILED;
+
+ return result;
+ }
}
--
Best Regards,
Regis.
