It seems JIRA is down for maintenance. If HARMONY-1904 is still open
perhaps it makes sense to put a counter in the while (...) { select...}
loop. And after every N loops, print a warning/diagnostic message. The
value for N would have to be tuned. I don't know what the best number would
be. 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.
On 10/20/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
On 10/20/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>
>
> Ivan Volosyuk wrote:
> > Well, I think that the solution is what Geir suggests. One think which
> > bothers me is following. EINTR can happen in different places and the
> > situations can be quite rare in some 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Weldon Washburn
Intel Middleware Products Division
