harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [classlib][luni] signalis interruptus in hysock
Date Thu, 26 Oct 2006 14:21:21 GMT


Fedotov, Alexei A wrote:
> Geir,
> 
> Do I understand correctly that you suggest the following?
> 
> 1. hysock_select as its name says should mimic a behavior of select, i.
> e. return the error code from select without changing it. It's ok to
> print a rare debug message.

Yes, that's what I had the other do (and no, I see no reason to print a 
debug message, as upper layers can print if they find an EINTR)

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

My plan is to fix it as fixed the other one.  It turns out that there 
are several layers between java and the OS...

geir

> 
> 
> With best regards,
> Alexei Fedotov,
> Intel Java & XML Engineering
> 
>> -----Original Message-----
>> From: Geir Magnusson Jr. [mailto: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