Andrey Chernyshev wrote:
On 8/23/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
Artem Aliev wrote:
> Gier,
>
> The DRLVM uses SIGUSR2 in thread suspend algorithm.
> hysock_select() returns EINTR error when the signal appears, and
> Socket.accept() throws exception.
>
> The New ThreadManager use thread_suspend() more extensively ( in lock
> reservation algorithm). So the problem appears more frequently.
Excellent - I knew there had to be an explanation as to why the same
symptom appears so much faster...
>
> Following patch to hysock.c fixes the problem in hysock.
> Probably classlib experts could provide better way to fix this problem.
>
This seems wrong - that we're going to make it everyone else's problem
The other way we can look at this as if the DRLVM was an arbitrary
user application code which is utilizing SIGUSR2 for some reason.
In this case the hysock implementation appears to be not immune to
such user code.
True - I wasn't meaning to imply that DRLVM was the problem, I was just
thinking in the larger sense (what about user code via JNI?). Sorry.
because we're using SIGUSR2. Is there a way to setup a handler such
that select() (and other things scattered about, including user native
code) don't have to worry about this?
I think that DRLVM correctly installs the SIGUSR2 handler with the
SA_RESTART flag which means that the interrupted function should be
restarted.
It looks like the actual problem here is that the select()
implementation on Linux is not restartable (POSIX says this is up to
specific select() implementation whether to restart or not).
Yes - Stevens talked about this exact issue, and you shouldn't depend on
things like select() being restarted if you are writing portable code.
I assume that people still use Stevens as a source for this stuff? Or
is there something newer? (I need something in electronic form, as I'd
have to buy a second airplane ticket just to have some place to put the
Stevens book...)
This can be workarounded in the hysock.c in a way that Artem suggested.
Note that the reference VM is also using SIGUSR2 for it's internal
purposes in the default configuration (see
http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/java.html), so
the DRLVM doesn't imply any additional restrictions on the user's code
from this point of view.
Perfect. I just didn't know, and this answers the question.
We may need, however, to add a command line option proposing usage of
the alternative signals similar to what RI does.
Anyways, it might be good if we can make the hysock implementation
more robust wrt signals.
I agree 100%. I'll check in the code, and then work on the hysock issue...
thx
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
