Geir Magnusson Jr. wrote:
Time to take another run at this since I didn't get any responses on
the drlvm thread.
We have the problem that DRLVM uses SIGUSR2 in the thread manager (not
an unreasonable thing to do, I believe) but this results in knocking
threads out of select() in hysock.c (and I'm sure we'll see it in
other places.)
Now, I'm not sure what the right course of action is. We have a
suggested patch from Artem that suggests we just ignore when the tread
is interrupted :
--- 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;
IIRC, months ago similar approach was discussed in another thread for
j.nio.channels.InterruptibleChannel implementation, but IMHO it can be a
workaround but is not acceptable as a solution, because
InterruptibleChannel is extensible by user application, i.e., user can
implement their own interruptible blocking I/O easily without
considering too much on thread sync issues, it's not reasonable to ask
user writing codes within a loop like this.
this works, but I'm bothered by the fact that we're just blindly
ignoring signals like this. I also think that I need to go and do
this everywhere we have a non-restarted interruptable blocking system
call.
Now, I'd like to get this fixed today, as it's high time for another
snapshot of the JRE and HDK, but w/o it, Tomcat runs for 2 seconds at
best :)
So - does anyone have any other bright ideas? Why don't we see this
with J9? Would it be better to do a per-thread signal mask after
asking the thread manager what signal it's using du jour? (Andrey
noted that Sun allows one to change the signals used, apparently to
prevent collision w/ user code vi JNI, I guess...)
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
