harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fedotov, Alexei A" <alexei.a.fedo...@intel.com>
Subject RE: [classlib][luni] signalis interruptus in hysock
Date Thu, 26 Oct 2006 14:14:01 GMT
Geir,

Do I understand correctly that you suggest the following?

1. hysock_select as its name says should mimic a behavior of select, i.
e. return the error code from select without changing it. It's ok to
print a rare debug message.

2. The correct place for the loop is the module where hysock_select is
called, or, let me be precise, class lib guys are to fix our networking
code.


With best regards,
Alexei Fedotov,
Intel Java & XML Engineering

>-----Original Message-----
>From: Geir Magnusson Jr. [mailto:geir@pobox.com]
>Sent: Wednesday, October 25, 2006 10:01 AM
>To: harmony-dev@incubator.apache.org
>Subject: Re: [classlib][luni] signalis interruptus in hysock
>
>
>
>Weldon Washburn wrote:
>> It seems JIRA is down for maintenance.  If HARMONY-1904 is still open
>> perhaps it makes sense to put a counter in the while (...) {
select...}
>> loop. And after every N loops, print a warning/diagnostic message.
>
>For whom and to what end?  Why not just return EINTR (in hysock speak)?
>
>> The
>> value for N would have to be tuned.  I don't know what the best
number
>> would
>> be. Given that 1904 patch is not the final solution, at least a
>diagnostic
>> that hints at where the system hangs would be useful.  It might make
>sense
>> to even print a stack trace.   Also, I agree with Ivan below.
Signals
>bugs
>> are very hard to debug.  And diagnostics can help us all understand
the
>> corner cases better.
>
>But so far, no one has shown that the system hangs, or can hang, simply
>because we return EINTR....
>
>geir
>
>>
>> On 10/20/06, Ivan Volosyuk <ivan.volosyuk@gmail.com> wrote:
>>>
>>> On 10/20/06, Geir Magnusson Jr. <geir@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
>>>
>>>
>>
>>

Mime
View raw message