. [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
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
: 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
-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
@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
-
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
@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
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
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
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.
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
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
: 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
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.
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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() {
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 =
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
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
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
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
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
42 matches
Mail list logo
