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: [drlvm] problem when TM patch applied
Date Wed, 23 Aug 2006 15:53:49 GMT
Andrey Chernyshev wrote:
> On 8/23/06, Geir Magnusson Jr. <geir@pobox.com> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message