RVM

handleHandshakeRequest should be called from enterNativeBlockedImpl

Details

  • Number of attachments :
    1

Description

handleHandshakeRequest should be called from enterNativeBlockedImpl. Otherwise, a thread that enters native after a soft handshake request is initiated and does not exit native until after the soft handshake completes will have not serviced the request even though the requester will be made to believe that it had.

I have a patch for this, and I'm testing it now. I won't commit it until we see the effect of previous commits on the stability of the system.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
David Grove added a comment -

Moving all unscheduled issues to 3.1. Please close or retarget to a different fix target as appropriate.

Show
David Grove added a comment - Moving all unscheduled issues to 3.1. Please close or retarget to a different fix target as appropriate.
Hide
Permalink
David Grove added a comment -

Defer to 3.1.1

Show
David Grove added a comment - Defer to 3.1.1
Hide
Permalink
David Grove added a comment -

bulk defer open issues to 3.1.2

Show
David Grove added a comment - bulk defer open issues to 3.1.2
Hide
Permalink
Erik Brangs added a comment -

When ignoring comment changes, the patch by Filip Pizlo seems quite similar to this commit.

The placement of handleHandshakeRequest() is different, however.

Show
Erik Brangs added a comment - When ignoring comment changes, the patch by Filip Pizlo seems quite similar to this commit . The placement of handleHandshakeRequest() is different, however.
Hide
Permalink
David Grove added a comment -

I looked and I think the order of calls is ok.

I merged in the missing comments in 10413:59b08be63d68

Show
David Grove added a comment - I looked and I think the order of calls is ok. I merged in the missing comments in 10413:59b08be63d68
Hide
Permalink
David Grove added a comment -

bulk close of all resolved issues in preparation for 3.1.3 release.

Show
David Grove added a comment - bulk close of all resolved issues in preparation for 3.1.3 release.

People

  • Assignee:
    Unassigned
    Reporter:
    Filip Pizlo
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: