You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Artem Aliev <ar...@gmail.com> on 2006/10/17 16:31:38 UTC
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. <ge...@pobox.com> 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. <ge...@pobox.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
Re: [classlib][luni] signalis interruptus in hysock
Posted by Ivan Volosyuk <iv...@gmail.com>.
On 10/25/06, Weldon Washburn <we...@gmail.com> wrote:
> On 10/24/06, Geir Magnusson Jr. <ge...@pobox.com> 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
Posted by Weldon Washburn <we...@gmail.com>.
On 10/24/06, Geir Magnusson Jr. <ge...@pobox.com> 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 <iv...@gmail.com> wrote:
> >>
> >> On 10/20/06, Geir Magnusson Jr. <ge...@pobox.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >>
> >>
> >
> >
>
--
Weldon Washburn
Intel Middleware Products Division
Re: [classlib][luni] signalis interruptus in hysock
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Ivan Volosyuk wrote:
> On 10/20/06, Geir Magnusson Jr. <ge...@pobox.com> 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
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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 <iv...@gmail.com> wrote:
>>
>> On 10/20/06, Geir Magnusson Jr. <ge...@pobox.com> 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: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
>
Re: [classlib][luni] signalis interruptus in hysock
Posted by Ivan Volosyuk <iv...@gmail.com>.
On 10/20/06, Geir Magnusson Jr. <ge...@pobox.com> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][luni] signalis interruptus in hysock
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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?
> We should find a
> way how to test the implementation.
+1!
:)
geir
> --
> Ivan
>
> On 10/19/06, Jeff Disher <jm...@gmail.com> 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 <iv...@gmail.com> 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. <ge...@pobox.com> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][luni] signalis interruptus in hysock
Posted by Ivan Volosyuk <iv...@gmail.com>.
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 <jm...@gmail.com> 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 <iv...@gmail.com> 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. <ge...@pobox.com> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][luni] signalis interruptus in hysock
Posted by Jeff Disher <jm...@gmail.com>.
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 <iv...@gmail.com> 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. <ge...@pobox.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
Re: [classlib][luni] signalis interruptus in hysock
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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. <ge...@pobox.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][luni] signalis interruptus in hysock
Posted by Ivan Volosyuk <iv...@gmail.com>.
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. <ge...@pobox.com> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][luni] signalis interruptus in hysock
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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. <ge...@pobox.com> 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. <ge...@pobox.com> 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. <ge...@pobox.com> 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: harmony-dev-unsubscribe@incubator.apache.org
>> >> > For additional commands, e-mail:
>> harmony-dev-help@incubator.apache.org
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>> >>
>> >>
>> >
>> >
>> ------------------------------------------------------------------------
>> >
>> > --- 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: harmony-dev-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][luni] signalis interruptus in hysock
Posted by Artem Aliev <ar...@gmail.com>.
Geir,
I create HARMONY-1904 issue for this case.
Thanks
Artem
On 10/17/06, Geir Magnusson Jr. <ge...@pobox.com> 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. <ge...@pobox.com> 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. <ge...@pobox.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> >> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >>
> >>
> >
> > ------------------------------------------------------------------------
> >
> > --- 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: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][luni] signalis interruptus in hysock
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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. <ge...@pobox.com> 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. <ge...@pobox.com> 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: harmony-dev-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
> ------------------------------------------------------------------------
>
> --- 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org