Artem Aliev wrote:
Following patch to hysock.c fixes the problem in hysock.
Probably classlib experts could provide better way to fix this problem.
--
Artem Aliev, Intel Middleware Products Division
--- modules/luni/src/main/native/port/linux/hysock.c
+++ modules/luni/src/main/native/port/linux/hysock.c
@@ -2570,11 +2570,16 @@ hysock_select (struct HyPortLibrary * po
I_32 rc = 0;
I_32 result = 0;
- result =
+ do
+ {
+ result =
select (nfds, readfds == NULL ? NULL : &readfds->handle,
writefds == NULL ? NULL : &writefds->handle,
exceptfds == NULL ? NULL : &exceptfds->handle,
timeout == NULL ? NULL : &timeout->time);
+ }
+ while (result == -1 && errno == EINTR);
+
if (result == -1)
{
rc = errno;
So, here's what bothers me - while it does fix the problem, it's fairly
course-grained. Why are we so sure we want to restart the select on any
interruption?
Could we simply :
1) ask the TM what signal it's using (because we might offer the option
to change this via command line like RI)
2) on a per-thread basis, mask out that signal (and any other we know
about) that we're using internally using pthread_sigmask ?
I don't remember my pthreads well enough. Sad.
One immediate downside is that we're still susceptible to signals user
JNI code is using, but that may be the expected state of things.
If anyone knows, I'm interested.
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
