New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix for rakudo/rakudo#2178 #2749
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The fix is done by implementing cooperation between dispatchers. If a dispatcher finds out that next call in the queue is a invocation handler with attribute $!dispatcher containing a object of descendant type of Metamodel::BaseDispatcher it passes control over to that dispatcher by calling either enter_with_args or enter_with_capture method. The subsequent dispatcher passes control back to the calling dispatcher upon exhausting its own queue. The known problems of this fix: - there is no clear way to determine if next call is a invocation handler. The approach used by this fix is to wrap the attempt to read from $!dispatcher attribute into a try block is hacky and would have performance penalty. Must be changed as soon as more straightforward approach is developed or found. - The enter_* methods are currently specific to the WrapDisptacher. So far there is seemingly no way to create a invocation handler with method or multi dispatcher in $!dispatcher and get such handler inserted into the WrapDispatcher queue. But neither there is no guaranty that no other such dispatcher would be developed in the future. For this reason the enter_* methods must be standartized and possibly moved into BaseDispatcher class.
A problem has been discovered which needs fixing before this PR is ready. |
For wrapper-like dispatchers (with WrapDispatcher being currently the only one) we won't set explicit dispatcher for the last candidate on the queue effectively allowing a control call like callsame/nextsame to obtain routine's default dispatcher. This fixes a situation when a wrapped method cannot pass control over to the next method on MethodDispatcher queue. rakudo#2178
The problem has been resolved, this PR is ready for review. |
MasterDuke17
reviewed
Mar 9, 2019
vrurg
added a commit
to vrurg/roast
that referenced
this pull request
Mar 9, 2019
In support to PR rakudo/rakudo#2749
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The fix is done by implementing cooperation between dispatchers. If a
dispatcher finds out that next call in the queue is a invocation handler
with attribute
$!dispatcher
containing a object of descendant type ofMetamodel::BaseDispatcher
it passes control over to that dispatcher bycalling either
enter_with_args
orenter_with_capture
method. Thesubsequent dispatcher passes control back to the calling dispatcher upon
exhausting its own queue.
The known problems of this fix:
handler. The approach used by this fix is to wrap the attempt to read
from
$!dispatcher
attribute into a try block is hacky and would haveperformance penalty. Must be changed as soon as more straightforward
approach is developed or found.
#2178