You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by "Geir Magnusson Jr." <ge...@pobox.com> on 2006/08/30 17:29:42 UTC
[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: 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>.
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: 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 Gregory Shimansky <gs...@gmail.com>.
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: 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
Re: [classlib][luni] signalis interruptus in hysock
Posted by Artem Aliev <ar...@gmail.com>.
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 "Geir Magnusson Jr." <ge...@pobox.com>.
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: 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 "Jimmy, Jing Lv" <fi...@gmail.com>.
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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
---------------------------------------------------------------------
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>.
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 "Geir Magnusson Jr." <ge...@pobox.com>.
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
Re: [classlib][luni] signalis interruptus in hysock
Posted by Weldon Washburn <we...@gmail.com>.
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?
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: 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>.
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: 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>.
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. <ge...@pobox.com> 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: 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 "Geir Magnusson Jr." <ge...@pobox.com>.
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: 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:
> 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: 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>.
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: 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>.
Alexey Varlamov wrote:
> 2006/8/31, Geir Magnusson Jr. <ge...@pobox.com>:
>>
>>
>> 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)
Yes, I've been suggesting that one for a week now. Great [or demented]
minds think alike, I suppose. My problem is that I have no experience
using this technique, and I don't always trust unix APIs :)
I guess before we go down that path, I'd like to once again appeal to
our brethren from IBM or elsewhere to tell us either that J9 doesn't use
signals (or they are very clever with them), and how or why.
geir
>
> --
> Alexey
>
>> geir
>>
>>
>> >
>> > [1] http://www.opengroup.org/onlinepubs/007908799/xsh/select.html
>> >
>> > On 8/31/06, Geir Magnusson Jr. <ge...@pobox.com> 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 PrivilegedExceptionAction<Method>() {
>> >> >> 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: 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 Alexey Varlamov <al...@gmail.com>.
2006/8/31, Geir Magnusson Jr. <ge...@pobox.com>:
>
>
> 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. <ge...@pobox.com> 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 PrivilegedExceptionAction<Method>() {
> >> >> 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: 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>.
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. <ge...@pobox.com> 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 PrivilegedExceptionAction<Method>() {
>> >> 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: 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 Anton Luht <an...@gmail.com>.
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. <ge...@pobox.com> 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 PrivilegedExceptionAction<Method>() {
> >> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Regards,
Anton Luht,
Intel Middleware Products 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 "Geir Magnusson Jr." <ge...@pobox.com>.
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 PrivilegedExceptionAction<Method>() {
>> 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: 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 "Jimmy, Jing Lv" <fi...@gmail.com>.
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 PrivilegedExceptionAction<Method>() {
> 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 :) )
> --
> Alexey
>
> 2006/8/31, Paulex Yang <pa...@gmail.com>:
>> 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: harmony-dev-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>> >
>> >
>>
>>
>> --
>> Paulex Yang
>> China Software Development Lab
>> IBM
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
---------------------------------------------------------------------
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 Paulex Yang <pa...@gmail.com>.
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/%3c448FBC7B.1040808@gmail.com%3e
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 PrivilegedExceptionAction<Method>() {
> 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 <pa...@gmail.com>:
>> 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: harmony-dev-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>> >
>> >
>>
>>
>> --
>> Paulex Yang
>> China Software Development Lab
>> IBM
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
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 Alexey Varlamov <al...@gmail.com>.
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 PrivilegedExceptionAction<Method>() {
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 <pa...@gmail.com>:
> 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: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>
> ---------------------------------------------------------------------
> 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>.
On Aug 30, 2006, at 11:04 PM, Paulex Yang wrote:
> 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.
So what was deemed acceptable as a solution?
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 Paulex Yang <pa...@gmail.com>.
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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
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