RE: [classlib][luni] signalis interruptus in hysock
Geir,
Tanks for your reply!
In code that calls the wrapper for the lowest-level select(), right?
Yes
pollSelectRead() // loop is here
hysock_select_read() // return code is propagated
hysock_select() // EINTR is renamed to
HYPORT_ERROR_SOCKET_INTERRUPTED
I don't understand this - what do you see as the real problem?
Interruption from select due to signals is a fact of life under linux.
This is a good question. 100% agree with your statement. I will try to
reproduce connection failures on Linux right after overcoming my SuSE
Linux problems with running DRLVM. If there are no connection failures,
than there is no problem.
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 31, 2006 2:30 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][luni] signalis interruptus in hysock
Fedotov, Alexei A wrote:
Geir, All,
I have examined class library code. It seems that the solution we
invented (return EINTR, then loop) was always in place. :-)
Few comments on understanding:
1. EINTR (=4) is renamed to HYPORT_ERROR_SOCKET_INTERRUPTED (=-9).
Yes, I did that in one place to have it fit into the portlib error code
set. Someone may have done it in another.
2. The loop is coded by means of goto select.
In code that calls the wrapper for the lowest-level select(), right?
3. The same pattern is dupdupduplicated several times.
That's another issue entirely :)
I have not examined all places, though there could be paths which do
not
fit the pattern. Honestly, I have examined the only path:
pollSelectRead() -
hysock_select_read() -
hysock_select()
Summary:
We can keep this issue open or close it as won't fix. Meanwhile we
should look for the real problem.
I don't understand this - what do you see as the real problem?
Interruption from select due to signals is a fact of life under linux.
geir
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 26, 2006 6:21 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][luni] signalis interruptus in hysock
Fedotov, Alexei A wrote:
Geir,
Do I understand correctly that you suggest the following?
1. hysock_select as its name says should mimic a behavior of
select,
i.
e. return the error code from select without changing it. It's ok
to
print a rare debug message.
Yes, that's what I had the other do (and no, I see no reason to
print a
debug message, as upper layers can print if they find an EINTR)
2. The correct place for the loop is the module where hysock_select
is
called, or, let me be precise, class lib guys are to fix our
networking
code.
My plan is to fix it as fixed the other one. It turns out that
there
are several layers between java and the OS...
geir
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 25, 2006 10:01 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][luni] signalis interruptus in hysock
Weldon Washburn wrote:
It seems JIRA is down for maintenance. If HARMONY-1904 is still
open
perhaps it makes sense to put a counter in the while (...) {
select...}
loop. And after every N loops, print a warning/diagnostic
message.
For whom and to what end? Why not just return EINTR (in hysock
speak)?
The
value for N would have to be tuned. I don't know what the best
number
would
be. Given that 1904 patch is not the final solution, at least a
diagnostic
that hints at where the system hangs would be useful. It might
make
sense
to even print a stack trace. Also, I agree with Ivan below.
Signals
bugs
are very hard to debug. And diagnostics can help us all
understand
the
corner cases better.
But so far, no one has shown that the system hangs, or can hang,
simply
because we return EINTR
geir
On 10/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Ivan Volosyuk wrote:
Well, I think that the solution is what Geir suggests. One
think
which
bothers me is following. EINTR can happen in different places
and
the
situations can be quite rare in some circumstances. It can
lead
to
hard to reproduce stability bugs (race conditions).
Can you give an example?
Half a year ago, I was working on the problem. Socket operations
get
sometimes interrupted. We have found out that it occurs sometime
after
GC. It was not quite easy as the application was quite big and
situation - quite rare.
Given the fact, that current implementation of monitor
reservation
code can stop other thread in quite random fashion we should
have
rock
solid support of EINTR handling everywhere the select(), poll()
calls
is used.
--
Ivan
Intel Enterprise
RE: [classlib][luni] signalis interruptus in hysock
Geir, All,
I have examined class library code. It seems that the solution we
invented (return EINTR, then loop) was always in place. :-)
Few comments on understanding:
1. EINTR (=4) is renamed to HYPORT_ERROR_SOCKET_INTERRUPTED (=-9).
2. The loop is coded by means of goto select.
3. The same pattern is dupdupduplicated several times.
I have not examined all places, though there could be paths which do not
fit the pattern. Honestly, I have examined the only path:
pollSelectRead() -
hysock_select_read() -
hysock_select()
Summary:
We can keep this issue open or close it as won't fix. Meanwhile we
should look for the real problem.
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 26, 2006 6:21 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][luni] signalis interruptus in hysock
Fedotov, Alexei A wrote:
Geir,
Do I understand correctly that you suggest the following?
1. hysock_select as its name says should mimic a behavior of select,
i.
e. return the error code from select without changing it. It's ok to
print a rare debug message.
Yes, that's what I had the other do (and no, I see no reason to print a
debug message, as upper layers can print if they find an EINTR)
2. The correct place for the loop is the module where hysock_select
is
called, or, let me be precise, class lib guys are to fix our
networking
code.
My plan is to fix it as fixed the other one. It turns out that there
are several layers between java and the OS...
geir
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 25, 2006 10:01 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][luni] signalis interruptus in hysock
Weldon Washburn wrote:
It seems JIRA is down for maintenance. If HARMONY-1904 is still
open
perhaps it makes sense to put a counter in the while (...) {
select...}
loop. And after every N loops, print a warning/diagnostic message.
For whom and to what end? Why not just return EINTR (in hysock
speak)?
The
value for N would have to be tuned. I don't know what the best
number
would
be. Given that 1904 patch is not the final solution, at least a
diagnostic
that hints at where the system hangs would be useful. It might
make
sense
to even print a stack trace. Also, I agree with Ivan below.
Signals
bugs
are very hard to debug. And diagnostics can help us all understand
the
corner cases better.
But so far, no one has shown that the system hangs, or can hang,
simply
because we return EINTR
geir
On 10/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Ivan Volosyuk wrote:
Well, I think that the solution is what Geir suggests. One think
which
bothers me is following. EINTR can happen in different places
and
the
situations can be quite rare in some circumstances. It can lead
to
hard to reproduce stability bugs (race conditions).
Can you give an example?
Half a year ago, I was working on the problem. Socket operations
get
sometimes interrupted. We have found out that it occurs sometime
after
GC. It was not quite easy as the application was quite big and
situation - quite rare.
Given the fact, that current implementation of monitor reservation
code can stop other thread in quite random fashion we should have
rock
solid support of EINTR handling everywhere the select(), poll()
calls
is used.
--
Ivan
Intel Enterprise Solutions Software Division
We should find a
way how to test the implementation.
+1!
:)
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
Re: [classlib][luni] signalis interruptus in hysock
Fedotov, Alexei A wrote:
Geir, All,
I have examined class library code. It seems that the solution we
invented (return EINTR, then loop) was always in place. :-)
Few comments on understanding:
1. EINTR (=4) is renamed to HYPORT_ERROR_SOCKET_INTERRUPTED (=-9).
Yes, I did that in one place to have it fit into the portlib error code
set. Someone may have done it in another.
2. The loop is coded by means of goto select.
In code that calls the wrapper for the lowest-level select(), right?
3. The same pattern is dupdupduplicated several times.
That's another issue entirely :)
I have not examined all places, though there could be paths which do not
fit the pattern. Honestly, I have examined the only path:
pollSelectRead() -
hysock_select_read() -
hysock_select()
Summary:
We can keep this issue open or close it as won't fix. Meanwhile we
should look for the real problem.
I don't understand this - what do you see as the real problem?
Interruption from select due to signals is a fact of life under linux.
geir
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 26, 2006 6:21 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][luni] signalis interruptus in hysock
Fedotov, Alexei A wrote:
Geir,
Do I understand correctly that you suggest the following?
1. hysock_select as its name says should mimic a behavior of select,
i.
e. return the error code from select without changing it. It's ok to
print a rare debug message.
Yes, that's what I had the other do (and no, I see no reason to print a
debug message, as upper layers can print if they find an EINTR)
2. The correct place for the loop is the module where hysock_select
is
called, or, let me be precise, class lib guys are to fix our
networking
code.
My plan is to fix it as fixed the other one. It turns out that there
are several layers between java and the OS...
geir
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 25, 2006 10:01 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][luni] signalis interruptus in hysock
Weldon Washburn wrote:
It seems JIRA is down for maintenance. If HARMONY-1904 is still
open
perhaps it makes sense to put a counter in the while (...) {
select...}
loop. And after every N loops, print a warning/diagnostic message.
For whom and to what end? Why not just return EINTR (in hysock
speak)?
The
value for N would have to be tuned. I don't know what the best
number
would
be. Given that 1904 patch is not the final solution, at least a
diagnostic
that hints at where the system hangs would be useful. It might
make
sense
to even print a stack trace. Also, I agree with Ivan below.
Signals
bugs
are very hard to debug. And diagnostics can help us all understand
the
corner cases better.
But so far, no one has shown that the system hangs, or can hang,
simply
because we return EINTR
geir
On 10/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Ivan Volosyuk wrote:
Well, I think that the solution is what Geir suggests. One think
which
bothers me is following. EINTR can happen in different places
and
the
situations can be quite rare in some circumstances. It can lead
to
hard to reproduce stability bugs (race conditions).
Can you give an example?
Half a year ago, I was working on the problem. Socket operations
get
sometimes interrupted. We have found out that it occurs sometime
after
GC. It was not quite easy as the application was quite big and
situation - quite rare.
Given the fact, that current implementation of monitor reservation
code can stop other thread in quite random fashion we should have
rock
solid support of EINTR handling everywhere the select(), poll()
calls
is used.
--
Ivan
Intel Enterprise Solutions Software Division
We should find a
way how to test the implementation.
+1!
:)
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
Re: [classlib][luni] signalis interruptus in hysock
On 10/25/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Fedotov, Alexei A wrote:
Guys,
Could you please help me to understand the following?
1. Is HARMONY-1904 actually a duplicate of my HARMONY-1879?
scanning quickly, I don't think so.
2. Ivan, do I remember correctly that you've already fixed that bug once
when debugging Eclipse long run failures? Where is that patch?
this bug arose when the new TM was added, which uses signals much more
aggressively.
geir
Well, the bug exists quite a long time and it was reproducible before.
Older TM also used signals for stopping threads for GC. The patch I
have created was not integrated before as it was almost the same as
the current suggested patch. The only difference was that it handled
timeout correctly (for other unixes).
--
Ivan
Thank you in advance.
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Weldon Washburn [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 25, 2006 5:36 PM
To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED]
Subject: Re: [classlib][luni] signalis interruptus in hysock
On 10/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Weldon Washburn wrote:
It seems JIRA is down for maintenance. If HARMONY-1904 is still
open
perhaps it makes sense to put a counter in the while (...) {
select...}
loop. And after every N loops, print a warning/diagnostic message.
For whom and to what end? Why not just return EINTR (in hysock
speak)?
The
value for N would have to be tuned. I don't know what the best
number
would
be. Given that 1904 patch is not the final solution, at least a
diagnostic
that hints at where the system hangs would be useful. It might
make
sense
to even print a stack trace. Also, I agree with Ivan below.
Signals
bugs
are very hard to debug. And diagnostics can help us all understand
the
corner cases better.
But so far, no one has shown that the system hangs, or can hang,
simply
because we return EINTR
Sorry for not being clear. I was reacting to the patch in 1904 itself.
Not
the bigger issue of fixing the upper layers to comprehend EINTR. My
understanding is that this patch does not fix the problem. This patch
does
not return EINTR. If for whatever reason this patch is committed, I
recommend adding the above diagnostic code so that we don't dig
ourselves
an
even deeper hole.
If it is decided 1904 should not be committed, it might make sense to
close it with won't fix.
geir
On 10/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Ivan Volosyuk wrote:
Well, I think that the solution is what Geir suggests. One
think
which
bothers me is following. EINTR can happen in different places
and
the
situations can be quite rare in some circumstances. It can
lead to
hard to reproduce stability bugs (race conditions).
Can you give an example?
Half a year ago, I was working on the problem. Socket operations
get
sometimes interrupted. We have found out that it occurs sometime
after
GC. It was not quite easy as the application was quite big and
situation - quite rare.
Given the fact, that current implementation of monitor reservation
code can stop other thread in quite random fashion we should have
rock
solid support of EINTR handling everywhere the select(), poll()
calls
is used.
--
Ivan
Intel Enterprise Solutions Software Division
We should find a
way how to test the implementation.
+1!
:)
geir
RE: [classlib][luni] signalis interruptus in hysock
Geir,
Do I understand correctly that you suggest the following?
1. hysock_select as its name says should mimic a behavior of select, i.
e. return the error code from select without changing it. It's ok to
print a rare debug message.
2. The correct place for the loop is the module where hysock_select is
called, or, let me be precise, class lib guys are to fix our networking
code.
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 25, 2006 10:01 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][luni] signalis interruptus in hysock
Weldon Washburn wrote:
It seems JIRA is down for maintenance. If HARMONY-1904 is still open
perhaps it makes sense to put a counter in the while (...) {
select...}
loop. And after every N loops, print a warning/diagnostic message.
For whom and to what end? Why not just return EINTR (in hysock speak)?
The
value for N would have to be tuned. I don't know what the best
number
would
be. Given that 1904 patch is not the final solution, at least a
diagnostic
that hints at where the system hangs would be useful. It might make
sense
to even print a stack trace. Also, I agree with Ivan below.
Signals
bugs
are very hard to debug. And diagnostics can help us all understand
the
corner cases better.
But so far, no one has shown that the system hangs, or can hang, simply
because we return EINTR
geir
On 10/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Ivan Volosyuk wrote:
Well, I think that the solution is what Geir suggests. One think
which
bothers me is following. EINTR can happen in different places
and
the
situations can be quite rare in some circumstances. It can lead
to
hard to reproduce stability bugs (race conditions).
Can you give an example?
Half a year ago, I was working on the problem. Socket operations get
sometimes interrupted. We have found out that it occurs sometime
after
GC. It was not quite easy as the application was quite big and
situation - quite rare.
Given the fact, that current implementation of monitor reservation
code can stop other thread in quite random fashion we should have
rock
solid support of EINTR handling everywhere the select(), poll()
calls
is used.
--
Ivan
Intel Enterprise Solutions Software Division
We should find a
way how to test the implementation.
+1!
:)
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
Re: [classlib][luni] signalis interruptus in hysock
Happy to look at that other patch, but I'm no one has convinced me that
handling the EINTR like I've done already the first time is a bad idea...
and I'm convinced that just swallowing it in the lowest level of the
library is a bad idea.
geir
Ivan Volosyuk wrote:
On 10/25/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Fedotov, Alexei A wrote:
Guys,
Could you please help me to understand the following?
1. Is HARMONY-1904 actually a duplicate of my HARMONY-1879?
scanning quickly, I don't think so.
2. Ivan, do I remember correctly that you've already fixed that bug
once
when debugging Eclipse long run failures? Where is that patch?
this bug arose when the new TM was added, which uses signals much more
aggressively.
geir
Well, the bug exists quite a long time and it was reproducible before.
Older TM also used signals for stopping threads for GC. The patch I
have created was not integrated before as it was almost the same as
the current suggested patch. The only difference was that it handled
timeout correctly (for other unixes).
--
Ivan
Thank you in advance.
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Weldon Washburn [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 25, 2006 5:36 PM
To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED]
Subject: Re: [classlib][luni] signalis interruptus in hysock
On 10/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Weldon Washburn wrote:
It seems JIRA is down for maintenance. If HARMONY-1904 is still
open
perhaps it makes sense to put a counter in the while (...) {
select...}
loop. And after every N loops, print a warning/diagnostic message.
For whom and to what end? Why not just return EINTR (in hysock
speak)?
The
value for N would have to be tuned. I don't know what the best
number
would
be. Given that 1904 patch is not the final solution, at least a
diagnostic
that hints at where the system hangs would be useful. It might
make
sense
to even print a stack trace. Also, I agree with Ivan below.
Signals
bugs
are very hard to debug. And diagnostics can help us all understand
the
corner cases better.
But so far, no one has shown that the system hangs, or can hang,
simply
because we return EINTR
Sorry for not being clear. I was reacting to the patch in 1904
itself.
Not
the bigger issue of fixing the upper layers to comprehend EINTR. My
understanding is that this patch does not fix the problem. This patch
does
not return EINTR. If for whatever reason this patch is committed, I
recommend adding the above diagnostic code so that we don't dig
ourselves
an
even deeper hole.
If it is decided 1904 should not be committed, it might make sense to
close it with won't fix.
geir
On 10/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Ivan Volosyuk wrote:
Well, I think that the solution is what Geir suggests. One
think
which
bothers me is following. EINTR can happen in different places
and
the
situations can be quite rare in some circumstances. It can
lead to
hard to reproduce stability bugs (race conditions).
Can you give an example?
Half a year ago, I was working on the problem. Socket operations
get
sometimes interrupted. We have found out that it occurs sometime
after
GC. It was not quite easy as the application was quite big and
situation - quite rare.
Given the fact, that current implementation of monitor reservation
code can stop other thread in quite random fashion we should have
rock
solid support of EINTR handling everywhere the select(), poll()
calls
is used.
--
Ivan
Intel Enterprise Solutions Software Division
We should find a
way how to test the implementation.
+1!
:)
geir
Re: [classlib][luni] signalis interruptus in hysock
Fedotov, Alexei A wrote:
Geir,
Do I understand correctly that you suggest the following?
1. hysock_select as its name says should mimic a behavior of select, i.
e. return the error code from select without changing it. It's ok to
print a rare debug message.
Yes, that's what I had the other do (and no, I see no reason to print a
debug message, as upper layers can print if they find an EINTR)
2. The correct place for the loop is the module where hysock_select is
called, or, let me be precise, class lib guys are to fix our networking
code.
My plan is to fix it as fixed the other one. It turns out that there
are several layers between java and the OS...
geir
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 25, 2006 10:01 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][luni] signalis interruptus in hysock
Weldon Washburn wrote:
It seems JIRA is down for maintenance. If HARMONY-1904 is still open
perhaps it makes sense to put a counter in the while (...) {
select...}
loop. And after every N loops, print a warning/diagnostic message.
For whom and to what end? Why not just return EINTR (in hysock speak)?
The
value for N would have to be tuned. I don't know what the best
number
would
be. Given that 1904 patch is not the final solution, at least a
diagnostic
that hints at where the system hangs would be useful. It might make
sense
to even print a stack trace. Also, I agree with Ivan below.
Signals
bugs
are very hard to debug. And diagnostics can help us all understand
the
corner cases better.
But so far, no one has shown that the system hangs, or can hang, simply
because we return EINTR
geir
On 10/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Ivan Volosyuk wrote:
Well, I think that the solution is what Geir suggests. One think
which
bothers me is following. EINTR can happen in different places
and
the
situations can be quite rare in some circumstances. It can lead
to
hard to reproduce stability bugs (race conditions).
Can you give an example?
Half a year ago, I was working on the problem. Socket operations get
sometimes interrupted. We have found out that it occurs sometime
after
GC. It was not quite easy as the application was quite big and
situation - quite rare.
Given the fact, that current implementation of monitor reservation
code can stop other thread in quite random fashion we should have
rock
solid support of EINTR handling everywhere the select(), poll()
calls
is used.
--
Ivan
Intel Enterprise Solutions Software Division
We should find a
way how to test the implementation.
+1!
:)
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
Re: [classlib][luni] signalis interruptus in hysock
Ivan Volosyuk wrote: On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Ivan Volosyuk wrote: Well, I think that the solution is what Geir suggests. One think which bothers me is following. EINTR can happen in different places and the situations can be quite rare in some circumstances. It can lead to hard to reproduce stability bugs (race conditions). Can you give an example? Half a year ago, I was working on the problem. Socket operations get sometimes interrupted. We have found out that it occurs sometime after GC. It was not quite easy as the application was quite big and situation - quite rare. I believe it is rare, but if the code deals with EINTR correctly, where can the race conditions come from? Given the fact, that current implementation of monitor reservation code can stop other thread in quite random fashion we should have rock solid support of EINTR handling everywhere the select(), poll() calls is used. Well... yeah. Not bury it. geir
Re: [classlib][luni] signalis interruptus in hysock
Weldon Washburn wrote:
It seems JIRA is down for maintenance. If HARMONY-1904 is still open
perhaps it makes sense to put a counter in the while (...) { select...}
loop. And after every N loops, print a warning/diagnostic message.
For whom and to what end? Why not just return EINTR (in hysock speak)?
The
value for N would have to be tuned. I don't know what the best number
would
be. Given that 1904 patch is not the final solution, at least a diagnostic
that hints at where the system hangs would be useful. It might make sense
to even print a stack trace. Also, I agree with Ivan below. Signals bugs
are very hard to debug. And diagnostics can help us all understand the
corner cases better.
But so far, no one has shown that the system hangs, or can hang, simply
because we return EINTR
geir
On 10/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Ivan Volosyuk wrote:
Well, I think that the solution is what Geir suggests. One think
which
bothers me is following. EINTR can happen in different places and the
situations can be quite rare in some circumstances. It can lead to
hard to reproduce stability bugs (race conditions).
Can you give an example?
Half a year ago, I was working on the problem. Socket operations get
sometimes interrupted. We have found out that it occurs sometime after
GC. It was not quite easy as the application was quite big and
situation - quite rare.
Given the fact, that current implementation of monitor reservation
code can stop other thread in quite random fashion we should have rock
solid support of EINTR handling everywhere the select(), poll() calls
is used.
--
Ivan
Intel Enterprise Solutions Software Division
We should find a
way how to test the implementation.
+1!
:)
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] signalis interruptus in hysock
On 10/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Weldon Washburn wrote:
It seems JIRA is down for maintenance. If HARMONY-1904 is still open
perhaps it makes sense to put a counter in the while (...) { select...}
loop. And after every N loops, print a warning/diagnostic message.
For whom and to what end? Why not just return EINTR (in hysock speak)?
The
value for N would have to be tuned. I don't know what the best number
would
be. Given that 1904 patch is not the final solution, at least a
diagnostic
that hints at where the system hangs would be useful. It might make
sense
to even print a stack trace. Also, I agree with Ivan below. Signals
bugs
are very hard to debug. And diagnostics can help us all understand the
corner cases better.
But so far, no one has shown that the system hangs, or can hang, simply
because we return EINTR
Sorry for not being clear. I was reacting to the patch in 1904 itself. Not
the bigger issue of fixing the upper layers to comprehend EINTR. My
understanding is that this patch does not fix the problem. This patch does
not return EINTR. If for whatever reason this patch is committed, I
recommend adding the above diagnostic code so that we don't dig ourselves an
even deeper hole.
If it is decided 1904 should not be committed, it might make sense to
close it with won't fix.
geir
On 10/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Ivan Volosyuk wrote:
Well, I think that the solution is what Geir suggests. One think
which
bothers me is following. EINTR can happen in different places and
the
situations can be quite rare in some circumstances. It can lead to
hard to reproduce stability bugs (race conditions).
Can you give an example?
Half a year ago, I was working on the problem. Socket operations get
sometimes interrupted. We have found out that it occurs sometime after
GC. It was not quite easy as the application was quite big and
situation - quite rare.
Given the fact, that current implementation of monitor reservation
code can stop other thread in quite random fashion we should have rock
solid support of EINTR handling everywhere the select(), poll() calls
is used.
--
Ivan
Intel Enterprise Solutions Software Division
We should find a
way how to test the implementation.
+1!
:)
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Weldon Washburn
Intel Middleware Products Division
Re: [classlib][luni] signalis interruptus in hysock
On 10/25/06, Weldon Washburn [EMAIL PROTECTED] wrote:
On 10/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Weldon Washburn wrote:
It seems JIRA is down for maintenance. If HARMONY-1904 is still open
perhaps it makes sense to put a counter in the while (...) { select...}
loop. And after every N loops, print a warning/diagnostic message.
For whom and to what end? Why not just return EINTR (in hysock speak)?
The
value for N would have to be tuned. I don't know what the best number
would
be. Given that 1904 patch is not the final solution, at least a
diagnostic
that hints at where the system hangs would be useful. It might make
sense
to even print a stack trace. Also, I agree with Ivan below. Signals
bugs
are very hard to debug. And diagnostics can help us all understand the
corner cases better.
But so far, no one has shown that the system hangs, or can hang, simply
because we return EINTR
Sorry for not being clear. I was reacting to the patch in 1904 itself. Not
the bigger issue of fixing the upper layers to comprehend EINTR. My
understanding is that this patch does not fix the problem. This patch does
not return EINTR. If for whatever reason this patch is committed, I
recommend adding the above diagnostic code so that we don't dig ourselves an
even deeper hole.
If it is decided 1904 should not be committed, it might make sense to
close it with won't fix.
I would prefer to close it as fixed when the correct solution will be found.
--
Ivan
Intel Enterprise Solutions Software Division
RE: [classlib][luni] signalis interruptus in hysock
Guys,
Could you please help me to understand the following?
1. Is HARMONY-1904 actually a duplicate of my HARMONY-1879?
2. Ivan, do I remember correctly that you've already fixed that bug once
when debugging Eclipse long run failures? Where is that patch?
Thank you in advance.
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Weldon Washburn [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 25, 2006 5:36 PM
To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED]
Subject: Re: [classlib][luni] signalis interruptus in hysock
On 10/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Weldon Washburn wrote:
It seems JIRA is down for maintenance. If HARMONY-1904 is still
open
perhaps it makes sense to put a counter in the while (...) {
select...}
loop. And after every N loops, print a warning/diagnostic message.
For whom and to what end? Why not just return EINTR (in hysock
speak)?
The
value for N would have to be tuned. I don't know what the best
number
would
be. Given that 1904 patch is not the final solution, at least a
diagnostic
that hints at where the system hangs would be useful. It might
make
sense
to even print a stack trace. Also, I agree with Ivan below.
Signals
bugs
are very hard to debug. And diagnostics can help us all understand
the
corner cases better.
But so far, no one has shown that the system hangs, or can hang,
simply
because we return EINTR
Sorry for not being clear. I was reacting to the patch in 1904 itself.
Not
the bigger issue of fixing the upper layers to comprehend EINTR. My
understanding is that this patch does not fix the problem. This patch
does
not return EINTR. If for whatever reason this patch is committed, I
recommend adding the above diagnostic code so that we don't dig
ourselves
an
even deeper hole.
If it is decided 1904 should not be committed, it might make sense to
close it with won't fix.
geir
On 10/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Ivan Volosyuk wrote:
Well, I think that the solution is what Geir suggests. One
think
which
bothers me is following. EINTR can happen in different places
and
the
situations can be quite rare in some circumstances. It can
lead to
hard to reproduce stability bugs (race conditions).
Can you give an example?
Half a year ago, I was working on the problem. Socket operations
get
sometimes interrupted. We have found out that it occurs sometime
after
GC. It was not quite easy as the application was quite big and
situation - quite rare.
Given the fact, that current implementation of monitor reservation
code can stop other thread in quite random fashion we should have
rock
solid support of EINTR handling everywhere the select(), poll()
calls
is used.
--
Ivan
Intel Enterprise Solutions Software Division
We should find a
way how to test the implementation.
+1!
:)
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
--
Weldon Washburn
Intel Middleware Products Division
Re: [classlib][luni] signalis interruptus in hysock
Fedotov, Alexei A wrote:
Guys,
Could you please help me to understand the following?
1. Is HARMONY-1904 actually a duplicate of my HARMONY-1879?
scanning quickly, I don't think so.
2. Ivan, do I remember correctly that you've already fixed that bug once
when debugging Eclipse long run failures? Where is that patch?
this bug arose when the new TM was added, which uses signals much more
aggressively.
geir
Thank you in advance.
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Weldon Washburn [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 25, 2006 5:36 PM
To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED]
Subject: Re: [classlib][luni] signalis interruptus in hysock
On 10/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Weldon Washburn wrote:
It seems JIRA is down for maintenance. If HARMONY-1904 is still
open
perhaps it makes sense to put a counter in the while (...) {
select...}
loop. And after every N loops, print a warning/diagnostic message.
For whom and to what end? Why not just return EINTR (in hysock
speak)?
The
value for N would have to be tuned. I don't know what the best
number
would
be. Given that 1904 patch is not the final solution, at least a
diagnostic
that hints at where the system hangs would be useful. It might
make
sense
to even print a stack trace. Also, I agree with Ivan below.
Signals
bugs
are very hard to debug. And diagnostics can help us all understand
the
corner cases better.
But so far, no one has shown that the system hangs, or can hang,
simply
because we return EINTR
Sorry for not being clear. I was reacting to the patch in 1904 itself.
Not
the bigger issue of fixing the upper layers to comprehend EINTR. My
understanding is that this patch does not fix the problem. This patch
does
not return EINTR. If for whatever reason this patch is committed, I
recommend adding the above diagnostic code so that we don't dig
ourselves
an
even deeper hole.
If it is decided 1904 should not be committed, it might make sense to
close it with won't fix.
geir
On 10/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Ivan Volosyuk wrote:
Well, I think that the solution is what Geir suggests. One
think
which
bothers me is following. EINTR can happen in different places
and
the
situations can be quite rare in some circumstances. It can
lead to
hard to reproduce stability bugs (race conditions).
Can you give an example?
Half a year ago, I was working on the problem. Socket operations
get
sometimes interrupted. We have found out that it occurs sometime
after
GC. It was not quite easy as the application was quite big and
situation - quite rare.
Given the fact, that current implementation of monitor reservation
code can stop other thread in quite random fashion we should have
rock
solid support of EINTR handling everywhere the select(), poll()
calls
is used.
--
Ivan
Intel Enterprise Solutions Software Division
We should find a
way how to test the implementation.
+1!
:)
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
--
Weldon Washburn
Intel Middleware Products Division
Re: [classlib][luni] signalis interruptus in hysock
It seems JIRA is down for maintenance. If HARMONY-1904 is still open
perhaps it makes sense to put a counter in the while (...) { select...}
loop. And after every N loops, print a warning/diagnostic message. The
value for N would have to be tuned. I don't know what the best number would
be. Given that 1904 patch is not the final solution, at least a diagnostic
that hints at where the system hangs would be useful. It might make sense
to even print a stack trace. Also, I agree with Ivan below. Signals bugs
are very hard to debug. And diagnostics can help us all understand the
corner cases better.
On 10/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Ivan Volosyuk wrote:
Well, I think that the solution is what Geir suggests. One think which
bothers me is following. EINTR can happen in different places and the
situations can be quite rare in some circumstances. It can lead to
hard to reproduce stability bugs (race conditions).
Can you give an example?
Half a year ago, I was working on the problem. Socket operations get
sometimes interrupted. We have found out that it occurs sometime after
GC. It was not quite easy as the application was quite big and
situation - quite rare.
Given the fact, that current implementation of monitor reservation
code can stop other thread in quite random fashion we should have rock
solid support of EINTR handling everywhere the select(), poll() calls
is used.
--
Ivan
Intel Enterprise Solutions Software Division
We should find a
way how to test the implementation.
+1!
:)
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Weldon Washburn
Intel Middleware Products Division
Re: [classlib][luni] signalis interruptus in hysock
On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Ivan Volosyuk wrote: Well, I think that the solution is what Geir suggests. One think which bothers me is following. EINTR can happen in different places and the situations can be quite rare in some circumstances. It can lead to hard to reproduce stability bugs (race conditions). Can you give an example? Half a year ago, I was working on the problem. Socket operations get sometimes interrupted. We have found out that it occurs sometime after GC. It was not quite easy as the application was quite big and situation - quite rare. Given the fact, that current implementation of monitor reservation code can stop other thread in quite random fashion we should have rock solid support of EINTR handling everywhere the select(), poll() calls is used. -- Ivan Intel Enterprise Solutions Software Division We should find a way how to test the implementation. +1! :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] signalis interruptus in hysock
The problem is larger than SA_RESTART since a VM can receive signals for which it did not set SA_RESTART. On some platforms, forcing EINTR is the only way to break a thread out of an indefinitely blocking syscall. Losing this information would cause us to lose the ability to perform these kinds of operations. If the lower level didn't generate the signal, it probably shouldn't assume its intention. The timeout handling is an issue which we can probably resolve by stating that the timeout value is undefined after a call to hysock_select. Does that make sense? Jeff. On 10/18/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: Why not? I understand your opinion, that EINTR should be handled in upper layers. But here we have somewhat buggy (strange) implementation specifics of select() and similar calls. Good functions like read() and write() and so on doesn't interrupt with SA_RESTART system calls, but select() does. I think it is low level issue and should be handled in the same low level layer. Handling it in upper layer may cause hard to detect bugs in that implementations. There are issues with timeout handling here to maintain platform independence (Linux implementation is different then POSIX, AFAIK), but it can be solved with minor performance decrease. -- Ivan On 10/18/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Thanks, but we're not going to eat EINTR Artem Aliev wrote: Geir, I create HARMONY-1904 issue for this case. Thanks Artem - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] signalis interruptus in hysock
Well, I think that the solution is what Geir suggests. One think which bothers me is following. EINTR can happen in different places and the situations can be quite rare in some circumstances. It can lead to hard to reproduce stability bugs (race conditions). We should find a way how to test the implementation. -- Ivan On 10/19/06, Jeff Disher [EMAIL PROTECTED] wrote: The problem is larger than SA_RESTART since a VM can receive signals for which it did not set SA_RESTART. On some platforms, forcing EINTR is the only way to break a thread out of an indefinitely blocking syscall. Losing this information would cause us to lose the ability to perform these kinds of operations. If the lower level didn't generate the signal, it probably shouldn't assume its intention. The timeout handling is an issue which we can probably resolve by stating that the timeout value is undefined after a call to hysock_select. Does that make sense? Jeff. On 10/18/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: Why not? I understand your opinion, that EINTR should be handled in upper layers. But here we have somewhat buggy (strange) implementation specifics of select() and similar calls. Good functions like read() and write() and so on doesn't interrupt with SA_RESTART system calls, but select() does. I think it is low level issue and should be handled in the same low level layer. Handling it in upper layer may cause hard to detect bugs in that implementations. There are issues with timeout handling here to maintain platform independence (Linux implementation is different then POSIX, AFAIK), but it can be solved with minor performance decrease. -- Ivan On 10/18/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Thanks, but we're not going to eat EINTR Artem Aliev wrote: Geir, I create HARMONY-1904 issue for this case. Thanks Artem -- Ivan Intel Enterprise Solutions Software Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] signalis interruptus in hysock
Ivan Volosyuk wrote: Why not? I understand your opinion, that EINTR should be handled in upper layers. But here we have somewhat buggy (strange) implementation specifics of select() and similar calls. There's nothing buggy about it - it's working exactly as it's supposed to. Good functions like read() and write() and so on doesn't interrupt with SA_RESTART system calls, but select() does. And that's clearly defined in the API - it's not a bug. It's stupid, but not a bug :) I think it is low level issue and should be handled in the same low level layer. Handling it in upper layer may cause hard to detect bugs in that implementations. Why? It's a perfectly valid return value. There are issues with timeout handling here to maintain platform independence (Linux implementation is different then POSIX, AFAIK), but it can be solved with minor performance decrease. -- Ivan On 10/18/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Thanks, but we're not going to eat EINTR Artem Aliev wrote: Geir, I create HARMONY-1904 issue for this case. Thanks Artem - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] signalis interruptus in hysock
Geir,
I create HARMONY-1904 issue for this case.
Thanks
Artem
On 10/17/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Artem Aliev wrote:
Gier,
I'd like to resurrect this topic.
Oh goody!
We try to run JBoss on Harmony and meet the same problem.
Here is an except from the stack trace:
java.net.SocketException: The call was cancelled
at
org.apache.harmony.luni.platform.OSNetworkSystem.availableStreamImpl(OSNetworkSystem.java)
at
org.apache.harmony.luni.platform.OSNetworkSystem.availableStream(OSNetworkSystem.java:216)
at
org.apache.harmony.luni.net.PlainSocketImpl.available(PlainSocketImpl.java:150)
at
org.apache.harmony.luni.net.SocketInputStream.available(SocketInputStream.java:50)
at
com.mysql.jdbc.util.ReadAheadInputStream.available(ReadAheadInputStream.java:212)
at com.mysql.jdbc.MysqlIO.clearInputStream(MysqlIO.java:774)
Actually, my old patch (attached) fix this problem too.
So could you please take a look at the patch one more time
or implement your fix for the availableStreamImpl() and other
functions that call
hysock_select().
Yes - that was something on my list. I knew that first iteration was
incomplete, but wanted to wait to see what happened. I still don't
agree that those low level calls should simply swallow the EINTR, but
let the higher levels in our 10,000 layer stack :) decide what to do.
Thanks
Artem
PS:
And one other comment on the proposed patch... it doesn't respect the
timeout as it restarts the select() with the original timeout..
# man select
On Linux, the function select modifies timeout to reflect the
amount of time not slept; most other implementations do not do
this. This causes problems both when Linux code which
reads timeout is ported to other operating systems, and when code is
ported to Linux that reuses a struct timeval for multiple
selects in a loop without reinitializing it. Consider timeout to
be
undefined after select returns.
PPS: FYI: the comments and revision for previous fix.
svn log modules/luni/src/main/native/luni/shared/socket.c
r441311 | geirm | 2006-09-08 04:51:36 +0400 (Fri, 08 Sep 2006) | 12 lines
modifications to hysock_select() to report when
interrupted, and then in pollSelectRead() in
socket.c for linux only to handle the
interrupt return code.
This passes all tests and also fixes the problem
with tomcat. I'd like to continue with the other
uses of hysock_select() in socket.c and elsewhere
but want to commit to let others review before
I go further
On 9/7/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
And one other comment on the proposed patch... it doesn't respect the
timeout as it restarts the select() with the original timeout...
Geir Magnusson Jr. wrote:
Weldon Washburn wrote:
On 9/1/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Artem Aliev wrote:
The hyport and hy* are a porting layer that provides os independent
interface.
hysock_select() does not return EINTR on windows why it should
do it
under linux?
either user presses Ctrl-c or ctrl-\ or VM uses other signals
for its
owns needs.
I think you just gave me the answer.
The *caller* to hysock_select() needs to decide what to do on
EINTR, not
hysock_select() itself.
I still don't think this is a perfect solution, but I think it's
better :)
Does the above solve the problem completely or is it a temporary
patch?
I don't know, but happy to call it a temporary patch - right now we're
stuck, because we can't even run tomcat and I want to do a new
snapshot.
Will the caller to hysock_select() need to have #ifdef Windows
#ifdef
Linux...?
We already have platform specific code that calls hysock_select()
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--- 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;
Re: [classlib][luni] signalis interruptus in hysock
Thanks, but we're not going to eat EINTR
Artem Aliev wrote:
Geir,
I create HARMONY-1904 issue for this case.
Thanks
Artem
On 10/17/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Artem Aliev wrote:
Gier,
I'd like to resurrect this topic.
Oh goody!
We try to run JBoss on Harmony and meet the same problem.
Here is an except from the stack trace:
java.net.SocketException: The call was cancelled
at
org.apache.harmony.luni.platform.OSNetworkSystem.availableStreamImpl(OSNetworkSystem.java)
at
org.apache.harmony.luni.platform.OSNetworkSystem.availableStream(OSNetworkSystem.java:216)
at
org.apache.harmony.luni.net.PlainSocketImpl.available(PlainSocketImpl.java:150)
at
org.apache.harmony.luni.net.SocketInputStream.available(SocketInputStream.java:50)
at
com.mysql.jdbc.util.ReadAheadInputStream.available(ReadAheadInputStream.java:212)
at com.mysql.jdbc.MysqlIO.clearInputStream(MysqlIO.java:774)
Actually, my old patch (attached) fix this problem too.
So could you please take a look at the patch one more time
or implement your fix for the availableStreamImpl() and other
functions that call
hysock_select().
Yes - that was something on my list. I knew that first iteration was
incomplete, but wanted to wait to see what happened. I still don't
agree that those low level calls should simply swallow the EINTR, but
let the higher levels in our 10,000 layer stack :) decide what to do.
Thanks
Artem
PS:
And one other comment on the proposed patch... it doesn't respect the
timeout as it restarts the select() with the original timeout..
# man select
On Linux, the function select modifies timeout to reflect the
amount of time not slept; most other implementations do not do
this. This causes problems both when Linux code which
reads timeout is ported to other operating systems, and when code is
ported to Linux that reuses a struct timeval for multiple
selects in a loop without reinitializing it. Consider timeout to
be
undefined after select returns.
PPS: FYI: the comments and revision for previous fix.
svn log modules/luni/src/main/native/luni/shared/socket.c
r441311 | geirm | 2006-09-08 04:51:36 +0400 (Fri, 08 Sep 2006) | 12
lines
modifications to hysock_select() to report when
interrupted, and then in pollSelectRead() in
socket.c for linux only to handle the
interrupt return code.
This passes all tests and also fixes the problem
with tomcat. I'd like to continue with the other
uses of hysock_select() in socket.c and elsewhere
but want to commit to let others review before
I go further
On 9/7/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
And one other comment on the proposed patch... it doesn't respect the
timeout as it restarts the select() with the original timeout...
Geir Magnusson Jr. wrote:
Weldon Washburn wrote:
On 9/1/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Artem Aliev wrote:
The hyport and hy* are a porting layer that provides os
independent
interface.
hysock_select() does not return EINTR on windows why it should
do it
under linux?
either user presses Ctrl-c or ctrl-\ or VM uses other signals
for its
owns needs.
I think you just gave me the answer.
The *caller* to hysock_select() needs to decide what to do on
EINTR, not
hysock_select() itself.
I still don't think this is a perfect solution, but I think it's
better :)
Does the above solve the problem completely or is it a temporary
patch?
I don't know, but happy to call it a temporary patch - right now
we're
stuck, because we can't even run tomcat and I want to do a new
snapshot.
Will the caller to hysock_select() need to have #ifdef Windows
#ifdef
Linux...?
We already have platform specific code that calls hysock_select()
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--- 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
Re: [classlib][luni] signalis interruptus in hysock
Why not? I understand your opinion, that EINTR should be handled in upper layers. But here we have somewhat buggy (strange) implementation specifics of select() and similar calls. Good functions like read() and write() and so on doesn't interrupt with SA_RESTART system calls, but select() does. I think it is low level issue and should be handled in the same low level layer. Handling it in upper layer may cause hard to detect bugs in that implementations. There are issues with timeout handling here to maintain platform independence (Linux implementation is different then POSIX, AFAIK), but it can be solved with minor performance decrease. -- Ivan On 10/18/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Thanks, but we're not going to eat EINTR Artem Aliev wrote: Geir, I create HARMONY-1904 issue for this case. Thanks Artem - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] signalis interruptus in hysock
Gier,
I'd like to resurrect this topic.
We try to run JBoss on Harmony and meet the same problem.
Here is an except from the stack trace:
java.net.SocketException: The call was cancelled
at
org.apache.harmony.luni.platform.OSNetworkSystem.availableStreamImpl(OSNetworkSystem.java)
at
org.apache.harmony.luni.platform.OSNetworkSystem.availableStream(OSNetworkSystem.java:216)
at
org.apache.harmony.luni.net.PlainSocketImpl.available(PlainSocketImpl.java:150)
at
org.apache.harmony.luni.net.SocketInputStream.available(SocketInputStream.java:50)
at
com.mysql.jdbc.util.ReadAheadInputStream.available(ReadAheadInputStream.java:212)
at com.mysql.jdbc.MysqlIO.clearInputStream(MysqlIO.java:774)
Actually, my old patch (attached) fix this problem too.
So could you please take a look at the patch one more time
or implement your fix for the availableStreamImpl() and other
functions that call
hysock_select().
Thanks
Artem
PS:
And one other comment on the proposed patch... it doesn't respect the
timeout as it restarts the select() with the original timeout..
# man select
On Linux, the function select modifies timeout to reflect the
amount of time not slept; most other implementations do not do
this. This causes problems both when Linux code which
reads timeout is ported to other operating systems, and when code is
ported to Linux that reuses a struct timeval for multiple
selects in a loop without reinitializing it. Consider timeout to
be
undefined after select returns.
PPS: FYI: the comments and revision for previous fix.
svn log modules/luni/src/main/native/luni/shared/socket.c
r441311 | geirm | 2006-09-08 04:51:36 +0400 (Fri, 08 Sep 2006) | 12 lines
modifications to hysock_select() to report when
interrupted, and then in pollSelectRead() in
socket.c for linux only to handle the
interrupt return code.
This passes all tests and also fixes the problem
with tomcat. I'd like to continue with the other
uses of hysock_select() in socket.c and elsewhere
but want to commit to let others review before
I go further
On 9/7/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
And one other comment on the proposed patch... it doesn't respect the
timeout as it restarts the select() with the original timeout...
Geir Magnusson Jr. wrote:
Weldon Washburn wrote:
On 9/1/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Artem Aliev wrote:
The hyport and hy* are a porting layer that provides os independent
interface.
hysock_select() does not return EINTR on windows why it should do it
under linux?
either user presses Ctrl-c or ctrl-\ or VM uses other signals for its
owns needs.
I think you just gave me the answer.
The *caller* to hysock_select() needs to decide what to do on EINTR, not
hysock_select() itself.
I still don't think this is a perfect solution, but I think it's
better :)
Does the above solve the problem completely or is it a temporary patch?
I don't know, but happy to call it a temporary patch - right now we're
stuck, because we can't even run tomcat and I want to do a new snapshot.
Will the caller to hysock_select() need to have #ifdef Windows
#ifdef
Linux...?
We already have platform specific code that calls hysock_select()
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--- 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;
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] signalis interruptus in hysock
Artem Aliev wrote:
Gier,
I'd like to resurrect this topic.
Oh goody!
We try to run JBoss on Harmony and meet the same problem.
Here is an except from the stack trace:
java.net.SocketException: The call was cancelled
at
org.apache.harmony.luni.platform.OSNetworkSystem.availableStreamImpl(OSNetworkSystem.java)
at
org.apache.harmony.luni.platform.OSNetworkSystem.availableStream(OSNetworkSystem.java:216)
at
org.apache.harmony.luni.net.PlainSocketImpl.available(PlainSocketImpl.java:150)
at
org.apache.harmony.luni.net.SocketInputStream.available(SocketInputStream.java:50)
at
com.mysql.jdbc.util.ReadAheadInputStream.available(ReadAheadInputStream.java:212)
at com.mysql.jdbc.MysqlIO.clearInputStream(MysqlIO.java:774)
Actually, my old patch (attached) fix this problem too.
So could you please take a look at the patch one more time
or implement your fix for the availableStreamImpl() and other
functions that call
hysock_select().
Yes - that was something on my list. I knew that first iteration was
incomplete, but wanted to wait to see what happened. I still don't
agree that those low level calls should simply swallow the EINTR, but
let the higher levels in our 10,000 layer stack :) decide what to do.
Thanks
Artem
PS:
And one other comment on the proposed patch... it doesn't respect the
timeout as it restarts the select() with the original timeout..
# man select
On Linux, the function select modifies timeout to reflect the
amount of time not slept; most other implementations do not do
this. This causes problems both when Linux code which
reads timeout is ported to other operating systems, and when code is
ported to Linux that reuses a struct timeval for multiple
selects in a loop without reinitializing it. Consider timeout to
be
undefined after select returns.
PPS: FYI: the comments and revision for previous fix.
svn log modules/luni/src/main/native/luni/shared/socket.c
r441311 | geirm | 2006-09-08 04:51:36 +0400 (Fri, 08 Sep 2006) | 12 lines
modifications to hysock_select() to report when
interrupted, and then in pollSelectRead() in
socket.c for linux only to handle the
interrupt return code.
This passes all tests and also fixes the problem
with tomcat. I'd like to continue with the other
uses of hysock_select() in socket.c and elsewhere
but want to commit to let others review before
I go further
On 9/7/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
And one other comment on the proposed patch... it doesn't respect the
timeout as it restarts the select() with the original timeout...
Geir Magnusson Jr. wrote:
Weldon Washburn wrote:
On 9/1/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Artem Aliev wrote:
The hyport and hy* are a porting layer that provides os independent
interface.
hysock_select() does not return EINTR on windows why it should
do it
under linux?
either user presses Ctrl-c or ctrl-\ or VM uses other signals
for its
owns needs.
I think you just gave me the answer.
The *caller* to hysock_select() needs to decide what to do on
EINTR, not
hysock_select() itself.
I still don't think this is a perfect solution, but I think it's
better :)
Does the above solve the problem completely or is it a temporary
patch?
I don't know, but happy to call it a temporary patch - right now we're
stuck, because we can't even run tomcat and I want to do a new
snapshot.
Will the caller to hysock_select() need to have #ifdef Windows
#ifdef
Linux...?
We already have platform specific code that calls hysock_select()
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--- 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;
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail:
Re: [classlib][luni] signalis interruptus in hysock
On 9/1/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Artem Aliev wrote: The hyport and hy* are a porting layer that provides os independent interface. hysock_select() does not return EINTR on windows why it should do it under linux? either user presses Ctrl-c or ctrl-\ or VM uses other signals for its owns needs. I think you just gave me the answer. The *caller* to hysock_select() needs to decide what to do on EINTR, not hysock_select() itself. I still don't think this is a perfect solution, but I think it's better :) Does the above solve the problem completely or is it a temporary patch? Will the caller to hysock_select() need to have #ifdef Windows #ifdef Linux...? I still want to know about J9 though. Maybe I need to go work for IBM again :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Weldon Washburn Intel Middleware Products Division
Re: [classlib][luni] signalis interruptus in hysock
Weldon Washburn wrote: On 9/1/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Artem Aliev wrote: The hyport and hy* are a porting layer that provides os independent interface. hysock_select() does not return EINTR on windows why it should do it under linux? either user presses Ctrl-c or ctrl-\ or VM uses other signals for its owns needs. I think you just gave me the answer. The *caller* to hysock_select() needs to decide what to do on EINTR, not hysock_select() itself. I still don't think this is a perfect solution, but I think it's better :) Does the above solve the problem completely or is it a temporary patch? I don't know, but happy to call it a temporary patch - right now we're stuck, because we can't even run tomcat and I want to do a new snapshot. Will the caller to hysock_select() need to have #ifdef Windows #ifdef Linux...? We already have platform specific code that calls hysock_select() geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] signalis interruptus in hysock
And one other comment on the proposed patch... it doesn't respect the timeout as it restarts the select() with the original timeout... Geir Magnusson Jr. wrote: Weldon Washburn wrote: On 9/1/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Artem Aliev wrote: The hyport and hy* are a porting layer that provides os independent interface. hysock_select() does not return EINTR on windows why it should do it under linux? either user presses Ctrl-c or ctrl-\ or VM uses other signals for its owns needs. I think you just gave me the answer. The *caller* to hysock_select() needs to decide what to do on EINTR, not hysock_select() itself. I still don't think this is a perfect solution, but I think it's better :) Does the above solve the problem completely or is it a temporary patch? I don't know, but happy to call it a temporary patch - right now we're stuck, because we can't even run tomcat and I want to do a new snapshot. Will the caller to hysock_select() need to have #ifdef Windows #ifdef Linux...? We already have platform specific code that calls hysock_select() geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] signalis interruptus in hysock
Geir Magnusson Jr. wrote: Artem Aliev wrote: The hyport and hy* are a porting layer that provides os independent interface. hysock_select() does not return EINTR on windows why it should do it under linux? either user presses Ctrl-c or ctrl-\ or VM uses other signals for its owns needs. I think you just gave me the answer. The *caller* to hysock_select() needs to decide what to do on EINTR, not hysock_select() itself. +1 to this solution, let's first keep portlib as it is, IIRC, there's many native methods refers it. But I'm still worry about ignore the signal in select(or its callers). I know few about the SIGUSR2, but I doubt if some user give a signal to the thread, how can our select process tell if the signal comes from user or form VM? Shall it continue anyway? Mask the signal may be a better way, select only stop when a certain signal comes with a certain mask. However it may still puzzle the native code if user also use masks. I was thinking the powerful SIGUSR2 may resolve some problem straightforwardly(like wakeup, etc.), but now I see there are still many problems. I believe J9 was not using any lib like SIGUSR2, maybe they create and handle threads themselves (RI may do like this as well). I'll keep an eye on the discussion, there are may select-related native codes to deal ... I still don't think this is a perfect solution, but I think it's better :) I still want to know about J9 though. Maybe I need to go work for IBM again :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv 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]
Re: [classlib][luni] signalis interruptus in hysock
This is a VMI extension introduced by HARMONY-635, and this modification
was discussed before in a very long thread[1]
But it's weird that, at revision r431077, it is removed, anyone knows
why:-(.
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/[EMAIL PROTECTED]
Alexey Varlamov wrote:
Guys,
Probably I missed that thread on InterruptibleChannel implementation,
but I've just hit on the following code in
java.nio.channels.spi.AbstractInterruptibleChannel:
static {
try {
setInterruptAction = AccessController
.doPrivileged(new PrivilegedExceptionActionMethod() {
public Method run() throws Exception {return
Thread.class.getDeclaredMethod(setInterruptAction,new
Class[] {
Runnable.class });
}
});
setInterruptAction.setAccessible(true);
} catch (Exception e) {
// FIXME: be accomodate before VM actually provides
// setInterruptAction method
// throw new Error(e);
}
}
There are no docs on j.l.Thread.setInterruptAction()... Does this code
snippet relate to the subject of this discussion?
--
Alexey
2006/8/31, Paulex Yang [EMAIL PROTECTED]:
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]
-
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]
Re: [classlib][luni] signalis interruptus in hysock
Hello, guys. Do not forgot about portability Hysock lib is a porting layer and it should work the same way on all platforms. The windows does not support signals at all So the porting layer should hide all OS depended signal processing including this select() problem. +1 to my patch. The patch removes implementation depended feature. The other question is how to interrupt read/select operations in hyport libraries. The close() operation as I remember interrupt read() operation but not interrupt select(). Select for example could be interrupted with special file that could be added to the file list. One more time: signals is not correct way because there is no signals under Win32 and there is no signals API in porting layer. Thanks Artem - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] signalis interruptus in hysock
2006/8/31, Geir Magnusson Jr. [EMAIL PROTECTED]:
Anton Luht wrote:
Hello,
Behaviour of select() with SA_RESTART can vary by platform - see [1]
---quote begins
[EINTR]
The select() function was interrupted before any of the selected events
occurred and before the timeout interval expired. If SA_RESTART has been
set
for the interrupting signal, it is implementation-dependent whether
select()
restarts or returns with [EINTR].
---quote ends
Thus, I think Artem's patch is correct - it just make behaviour of
select() not dependent on the underlying platform - the call is
restarted just like read() and write() do.
Hmmm.
Artem's patch does it for all signals. You can set the sighandler to
SA_RESTART on a *per signal* basis. So there's a difference. I'm not
sure if it's a meaningful difference, but it's there.
I'm not an expert in pthreads, but why not use pthread_sigmask[1]
then? Just block SIGUSR2 before select() and unblock/reset upon
return. Better yet, first ask a VM if it uses any signals internally
like DRLVM does, and then block those if any. This requires minor VMI
extension, though.
[1] int pthread_sigmask(int how, const sigset_t *set, sigset_t *oset);
(see http://www.opengroup.org/onlinepubs/007908799/xsh/sigprocmask.html)
--
Alexey
geir
[1] http://www.opengroup.org/onlinepubs/007908799/xsh/select.html
On 8/31/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
On Aug 31, 2006, at 3:03 AM, Jimmy, Jing Lv wrote:
Alexey Varlamov wrote:
Guys,
Probably I missed that thread on InterruptibleChannel implementation,
but I've just hit on the following code in
java.nio.channels.spi.AbstractInterruptibleChannel:
static {
try {
setInterruptAction = AccessController
.doPrivileged(new PrivilegedExceptionActionMethod() {
public Method run() throws Exception {return
Thread.class.getDeclaredMethod(setInterruptAction,
new Class[] {
Runnable.class });
}
});
setInterruptAction.setAccessible(true);
} catch (Exception e) {
// FIXME: be accomodate before VM actually provides
// setInterruptAction method
// throw new Error(e);
}
}
There are no docs on j.l.Thread.setInterruptAction()... Does this
code
snippet relate to the subject of this discussion?
Hi,
The SIGUSR2 is much more powerful than I think. If it can
really break select operation without other harmful side-effect, I
believe it is a good way to Interrupt Channel.
IIRC, setInterruptAction is used if VM can not interrupt some I/
O blocking operation, like select(), so it set a callback and ask
classlib method to stop them(close fd, etc). But if SIGUSR2 works
so well, I doubt it is not necessary then.
BTW, can it break socket read/write or other blocking operation
as well? (I'm very interested in how does it work, as common thread
mechanism know nothing how to stop a certain I/O :) )
Yes, it's one of the 'features' of signals in unix. So read() and
write() are also affected - they can return from a blocking operation
with nothing read and errno set to EINTR.
SIGUSR2 is not in itself any more powerful than SIGUSR1 - they all
have the same effect, namely a software interrupt.
I looked in DRLVM and it appears that the right thing is being done -
namely the sighandler is being setup w/ the SA_RESTART flag, so that
system calls that can be restarted are restarted. Experimentation on
ubuntu shows that read() can be dealt with this way, but select()
doesn't appear to be able to... IOW, I can get it so signals are
caught and handled and read() is automatically restarted - it doesn't
complete on the signal and therefore never appears to me to be
interrupted, where I cant' get select() to behave that way it
always completes when a signal is caught.
This is consistent with Stevens, although he notes that in SVR4,
select() is restarted. :/ Of course Stevens is pre-linux, and still
talks about modems. It's truly a great reference for this, but would
be nice if it was up-to-date wrt linux. The problem is that the
author died a few years ago...
So I don't know what to do. I'm hoping someone can tell us how J9
does this - the obvious answer is that J9 doesn't use any signals,
but I'm not sure if I buy that yet.
If we employ the patch, then our socket listening code can't be
interrupted, and I'm pretty uncomfortable with that.
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] signalis interruptus in hysock
Artem Aliev wrote: Hello, guys. Do not forgot about portability Hysock lib is a porting layer and it should work the same way on all platforms. The windows does not support signals at all So the porting layer should hide all OS depended signal processing including this select() problem. +1 to my patch. The patch removes implementation depended feature. That's crazy. This isn't an implementation dependent feature - it's a side effect. The other question is how to interrupt read/select operations in hyport libraries. The close() operation as I remember interrupt read() operation but not interrupt select(). Select for example could be interrupted with special file that could be added to the file list. This is just getting worse and worse. One more time: signals is not correct way because there is no signals under Win32 and there is no signals API in porting layer. Right, but this isn't a feature we've put into the linux version, it's a side effect. Thanks Artem - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] signalis interruptus in hysock
Geir Magnusson Jr. wrote: Artem Aliev wrote: Hello, guys. Do not forgot about portability Hysock lib is a porting layer and it should work the same way on all platforms. The windows does not support signals at all So the porting layer should hide all OS depended signal processing including this select() problem. +1 to my patch. The patch removes implementation depended feature. That's crazy. This isn't an implementation dependent feature - it's a side effect. Sorry - this came across wrong. I was just kidding, (and in the lines below), but for a non-native english speaker, you might mis-interpret. The key is that signals are an important part of Unix IPC - for example, what happens w/ a ctrl-c? Will these processes (yes, under linux, a thread is a process) quit? I worry about this and other side effects by masking *all* signals like we'd be effectively be doing... The other question is how to interrupt read/select operations in hyport libraries. The close() operation as I remember interrupt read() operation but not interrupt select(). Select for example could be interrupted with special file that could be added to the file list. This is just getting worse and worse. One more time: signals is not correct way because there is no signals under Win32 and there is no signals API in porting layer. Right, but this isn't a feature we've put into the linux version, it's a side effect. Thanks Artem - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] signalis interruptus in hysock
Gier, That's crazy. This isn't an implementation dependent feature - it's a side effect. The standard says: It is implementation-dependent behaviour, not a side effect :) http://www.opengroup.org/onlinepubs/007908799/xsh/select.html ---quote begins [EINTR] The select() function was interrupted before any of the selected events occurred and before the timeout interval expired. If SA_RESTART has been set for the interrupting signal, it is implementation-dependent whether select() restarts or returns with [EINTR]. ---quote ends The key is that signals are an important part of Unix IPC - for example, what happens w/ a ctrl-c? Will these processes (yes, under linux, a thread is a process) quit? The hyport and hy* are a porting layer that provides os independent interface. hysock_select() does not return EINTR on windows why it should do it under linux? either user presses Ctrl-c or ctrl-\ or VM uses other signals for its owns needs. By the way It looks like hyport library try to provide portable interface for signal handling. So we handle the signals in OS independent way. It setups handler for the all commonly used signals with SA_RESTART flag. See classlib/modules/luni/src/main/native/port/linux/hysignal.c The drlvm override some of the handlers but also use the SA_RESTART. Thus signals should not interrupt system calls in hyport base implementations. So the patch should not provide other side effects. Thanks Artem On 9/1/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Geir Magnusson Jr. wrote: Artem Aliev wrote: Hello, guys. Do not forgot about portability Hysock lib is a porting layer and it should work the same way on all platforms. The windows does not support signals at all So the porting layer should hide all OS depended signal processing including this select() problem. +1 to my patch. The patch removes implementation depended feature. That's crazy. This isn't an implementation dependent feature - it's a side effect. Sorry - this came across wrong. I was just kidding, (and in the lines below), but for a non-native english speaker, you might mis-interpret. The key is that signals are an important part of Unix IPC - for example, what happens w/ a ctrl-c? Will these processes (yes, under linux, a thread is a process) quit? I worry about this and other side effects by masking *all* signals like we'd be effectively be doing... The other question is how to interrupt read/select operations in hyport libraries. The close() operation as I remember interrupt read() operation but not interrupt select(). Select for example could be interrupted with special file that could be added to the file list. This is just getting worse and worse. One more time: signals is not correct way because there is no signals under Win32 and there is no signals API in porting layer. Right, but this isn't a feature we've put into the linux version, it's a side effect. Thanks Artem - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] signalis interruptus in hysock
Artem Aliev wrote: Gier, That's crazy. This isn't an implementation dependent feature - it's a side effect. The standard says: It is implementation-dependent behaviour, not a side effect :) http://www.opengroup.org/onlinepubs/007908799/xsh/select.html ---quote begins [EINTR] The select() function was interrupted before any of the selected events occurred and before the timeout interval expired. If SA_RESTART has been set for the interrupting signal, it is implementation-dependent whether select() restarts or returns with [EINTR]. ---quote ends You are misunderstanding what I said. How select() behaves with respect to restart is implementation-dependent. The fact that our classlibrary now falls out of select() is a side-effect of the fact that other code in the combined program of DRLVM + classlib uses signals. It's the uses signals part that's key. That's what I mean by side effect, because until now, there has been no discussion and/or coordination with respect to the assumptions of signal usage under unix in the project. The key is that signals are an important part of Unix IPC - for example, what happens w/ a ctrl-c? Will these processes (yes, under linux, a thread is a process) quit? The hyport and hy* are a porting layer that provides os independent interface. hysock_select() does not return EINTR on windows why it should do it under linux? The windows version returns WSAEINVAL and unix doesn't. You are mixing up two issues, #1 being Do we want platform-independent return codes (which has nothing to do with this) and #2 being how to ensure robust and correct behavior of our networking stack. either user presses Ctrl-c or ctrl-\ or VM uses other signals for its owns needs. I'm saying that I don't understand the implications of ignoring all signals without any coordination, design or planning. it would be like ignoring all Events in win32. By the way It looks like hyport library try to provide portable interface for signal handling. So we handle the signals in OS independent way. It setups handler for the all commonly used signals with SA_RESTART flag. See classlib/modules/luni/src/main/native/port/linux/hysignal.c The drlvm override some of the handlers but also use the SA_RESTART. Thus signals should not interrupt system calls in hyport base implementations. So the patch should not provide other side effects. I understand this. This isn't the issue. The issue is : 1) will it matter if our select() calls ignore all signals? 2) Is there anything we can learn from J9 from this So far, you haven't said why it won't matter. (And I don't expect you to answer #2...) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] signalis interruptus in hysock
Artem Aliev wrote: The hyport and hy* are a porting layer that provides os independent interface. hysock_select() does not return EINTR on windows why it should do it under linux? either user presses Ctrl-c or ctrl-\ or VM uses other signals for its owns needs. I think you just gave me the answer. The *caller* to hysock_select() needs to decide what to do on EINTR, not hysock_select() itself. I still don't think this is a perfect solution, but I think it's better :) I still want to know about J9 though. Maybe I need to go work for IBM again :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] signalis interruptus in hysock
Guys,
Probably I missed that thread on InterruptibleChannel implementation,
but I've just hit on the following code in
java.nio.channels.spi.AbstractInterruptibleChannel:
static {
try {
setInterruptAction = AccessController
.doPrivileged(new PrivilegedExceptionActionMethod() {
public Method run() throws Exception {
return
Thread.class.getDeclaredMethod(setInterruptAction, new
Class[] {
Runnable.class });
}
});
setInterruptAction.setAccessible(true);
} catch (Exception e) {
// FIXME: be accomodate before VM actually provides
// setInterruptAction method
// throw new Error(e);
}
}
There are no docs on j.l.Thread.setInterruptAction()... Does this code
snippet relate to the subject of this discussion?
--
Alexey
2006/8/31, Paulex Yang [EMAIL PROTECTED]:
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]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] signalis interruptus in hysock
On Aug 31, 2006, at 3:03 AM, Jimmy, Jing Lv wrote:
Alexey Varlamov wrote:
Guys,
Probably I missed that thread on InterruptibleChannel implementation,
but I've just hit on the following code in
java.nio.channels.spi.AbstractInterruptibleChannel:
static {
try {
setInterruptAction = AccessController
.doPrivileged(new PrivilegedExceptionActionMethod() {
public Method run() throws Exception {return
Thread.class.getDeclaredMethod(setInterruptAction,
new Class[] {
Runnable.class });
}
});
setInterruptAction.setAccessible(true);
} catch (Exception e) {
// FIXME: be accomodate before VM actually provides
// setInterruptAction method
// throw new Error(e);
}
}
There are no docs on j.l.Thread.setInterruptAction()... Does this
code
snippet relate to the subject of this discussion?
Hi,
The SIGUSR2 is much more powerful than I think. If it can
really break select operation without other harmful side-effect, I
believe it is a good way to Interrupt Channel.
IIRC, setInterruptAction is used if VM can not interrupt some I/
O blocking operation, like select(), so it set a callback and ask
classlib method to stop them(close fd, etc). But if SIGUSR2 works
so well, I doubt it is not necessary then.
BTW, can it break socket read/write or other blocking operation
as well? (I'm very interested in how does it work, as common thread
mechanism know nothing how to stop a certain I/O :) )
Yes, it's one of the 'features' of signals in unix. So read() and
write() are also affected - they can return from a blocking operation
with nothing read and errno set to EINTR.
SIGUSR2 is not in itself any more powerful than SIGUSR1 - they all
have the same effect, namely a software interrupt.
I looked in DRLVM and it appears that the right thing is being done -
namely the sighandler is being setup w/ the SA_RESTART flag, so that
system calls that can be restarted are restarted. Experimentation on
ubuntu shows that read() can be dealt with this way, but select()
doesn't appear to be able to... IOW, I can get it so signals are
caught and handled and read() is automatically restarted - it doesn't
complete on the signal and therefore never appears to me to be
interrupted, where I cant' get select() to behave that way it
always completes when a signal is caught.
This is consistent with Stevens, although he notes that in SVR4,
select() is restarted. :/ Of course Stevens is pre-linux, and still
talks about modems. It's truly a great reference for this, but would
be nice if it was up-to-date wrt linux. The problem is that the
author died a few years ago...
So I don't know what to do. I'm hoping someone can tell us how J9
does this - the obvious answer is that J9 doesn't use any signals,
but I'm not sure if I buy that yet.
If we employ the patch, then our socket listening code can't be
interrupted, and I'm pretty uncomfortable with that.
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] signalis interruptus in hysock
Hello,
Behaviour of select() with SA_RESTART can vary by platform - see [1]
---quote begins
[EINTR]
The select() function was interrupted before any of the selected events
occurred and before the timeout interval expired. If SA_RESTART has been set
for the interrupting signal, it is implementation-dependent whether select()
restarts or returns with [EINTR].
---quote ends
Thus, I think Artem's patch is correct - it just make behaviour of
select() not dependent on the underlying platform - the call is
restarted just like read() and write() do.
[1] http://www.opengroup.org/onlinepubs/007908799/xsh/select.html
On 8/31/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
On Aug 31, 2006, at 3:03 AM, Jimmy, Jing Lv wrote:
Alexey Varlamov wrote:
Guys,
Probably I missed that thread on InterruptibleChannel implementation,
but I've just hit on the following code in
java.nio.channels.spi.AbstractInterruptibleChannel:
static {
try {
setInterruptAction = AccessController
.doPrivileged(new PrivilegedExceptionActionMethod() {
public Method run() throws Exception {return
Thread.class.getDeclaredMethod(setInterruptAction,
new Class[] {
Runnable.class });
}
});
setInterruptAction.setAccessible(true);
} catch (Exception e) {
// FIXME: be accomodate before VM actually provides
// setInterruptAction method
// throw new Error(e);
}
}
There are no docs on j.l.Thread.setInterruptAction()... Does this
code
snippet relate to the subject of this discussion?
Hi,
The SIGUSR2 is much more powerful than I think. If it can
really break select operation without other harmful side-effect, I
believe it is a good way to Interrupt Channel.
IIRC, setInterruptAction is used if VM can not interrupt some I/
O blocking operation, like select(), so it set a callback and ask
classlib method to stop them(close fd, etc). But if SIGUSR2 works
so well, I doubt it is not necessary then.
BTW, can it break socket read/write or other blocking operation
as well? (I'm very interested in how does it work, as common thread
mechanism know nothing how to stop a certain I/O :) )
Yes, it's one of the 'features' of signals in unix. So read() and
write() are also affected - they can return from a blocking operation
with nothing read and errno set to EINTR.
SIGUSR2 is not in itself any more powerful than SIGUSR1 - they all
have the same effect, namely a software interrupt.
I looked in DRLVM and it appears that the right thing is being done -
namely the sighandler is being setup w/ the SA_RESTART flag, so that
system calls that can be restarted are restarted. Experimentation on
ubuntu shows that read() can be dealt with this way, but select()
doesn't appear to be able to... IOW, I can get it so signals are
caught and handled and read() is automatically restarted - it doesn't
complete on the signal and therefore never appears to me to be
interrupted, where I cant' get select() to behave that way it
always completes when a signal is caught.
This is consistent with Stevens, although he notes that in SVR4,
select() is restarted. :/ Of course Stevens is pre-linux, and still
talks about modems. It's truly a great reference for this, but would
be nice if it was up-to-date wrt linux. The problem is that the
author died a few years ago...
So I don't know what to do. I'm hoping someone can tell us how J9
does this - the obvious answer is that J9 doesn't use any signals,
but I'm not sure if I buy that yet.
If we employ the patch, then our socket listening code can't be
interrupted, and I'm pretty uncomfortable with that.
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Regards,
Anton Luht,
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] signalis interruptus in hysock
Anton Luht wrote:
Hello,
Behaviour of select() with SA_RESTART can vary by platform - see [1]
---quote begins
[EINTR]
The select() function was interrupted before any of the selected events
occurred and before the timeout interval expired. If SA_RESTART has been
set
for the interrupting signal, it is implementation-dependent whether
select()
restarts or returns with [EINTR].
---quote ends
Thus, I think Artem's patch is correct - it just make behaviour of
select() not dependent on the underlying platform - the call is
restarted just like read() and write() do.
Hmmm.
Artem's patch does it for all signals. You can set the sighandler to
SA_RESTART on a *per signal* basis. So there's a difference. I'm not
sure if it's a meaningful difference, but it's there.
geir
[1] http://www.opengroup.org/onlinepubs/007908799/xsh/select.html
On 8/31/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
On Aug 31, 2006, at 3:03 AM, Jimmy, Jing Lv wrote:
Alexey Varlamov wrote:
Guys,
Probably I missed that thread on InterruptibleChannel implementation,
but I've just hit on the following code in
java.nio.channels.spi.AbstractInterruptibleChannel:
static {
try {
setInterruptAction = AccessController
.doPrivileged(new PrivilegedExceptionActionMethod() {
public Method run() throws Exception {return
Thread.class.getDeclaredMethod(setInterruptAction,
new Class[] {
Runnable.class });
}
});
setInterruptAction.setAccessible(true);
} catch (Exception e) {
// FIXME: be accomodate before VM actually provides
// setInterruptAction method
// throw new Error(e);
}
}
There are no docs on j.l.Thread.setInterruptAction()... Does this
code
snippet relate to the subject of this discussion?
Hi,
The SIGUSR2 is much more powerful than I think. If it can
really break select operation without other harmful side-effect, I
believe it is a good way to Interrupt Channel.
IIRC, setInterruptAction is used if VM can not interrupt some I/
O blocking operation, like select(), so it set a callback and ask
classlib method to stop them(close fd, etc). But if SIGUSR2 works
so well, I doubt it is not necessary then.
BTW, can it break socket read/write or other blocking operation
as well? (I'm very interested in how does it work, as common thread
mechanism know nothing how to stop a certain I/O :) )
Yes, it's one of the 'features' of signals in unix. So read() and
write() are also affected - they can return from a blocking operation
with nothing read and errno set to EINTR.
SIGUSR2 is not in itself any more powerful than SIGUSR1 - they all
have the same effect, namely a software interrupt.
I looked in DRLVM and it appears that the right thing is being done -
namely the sighandler is being setup w/ the SA_RESTART flag, so that
system calls that can be restarted are restarted. Experimentation on
ubuntu shows that read() can be dealt with this way, but select()
doesn't appear to be able to... IOW, I can get it so signals are
caught and handled and read() is automatically restarted - it doesn't
complete on the signal and therefore never appears to me to be
interrupted, where I cant' get select() to behave that way it
always completes when a signal is caught.
This is consistent with Stevens, although he notes that in SVR4,
select() is restarted. :/ Of course Stevens is pre-linux, and still
talks about modems. It's truly a great reference for this, but would
be nice if it was up-to-date wrt linux. The problem is that the
author died a few years ago...
So I don't know what to do. I'm hoping someone can tell us how J9
does this - the obvious answer is that J9 doesn't use any signals,
but I'm not sure if I buy that yet.
If we employ the patch, then our socket listening code can't be
interrupted, and I'm pretty uncomfortable with that.
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][luni] signalis interruptus in hysock
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;
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]
Re: [classlib][luni] signalis interruptus in hysock
On Wednesday 30 August 2006 19:29 Geir Magnusson Jr. wrote: 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...) I could be mistaken but I think pthread_kill which is supposed to signal just a single thread works in a following way - it kills the whole process but allows the signal to just one thread. The blocking calls like select are interrupted anyway since signal is process wide and there is no way to make it interrupt only one thread. -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] signalis interruptus in hysock
On Aug 30, 2006, at 8:04 PM, Gregory Shimansky wrote: On Wednesday 30 August 2006 19:29 Geir Magnusson Jr. wrote: 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...) I could be mistaken but I think pthread_kill which is supposed to signal just a single thread works in a following way - it kills the whole process but allows the signal to just one thread. The blocking calls like select are interrupted anyway since signal is process wide and there is no way to make it interrupt only one thread. Right - I was thinking a per-thread signal mask... geir -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
