Skip to content
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

Spawning operation on new thread if remaining stack space becomes too small #2190

Merged
merged 2 commits into from Jun 1, 2016

Conversation

Projects
None yet
2 participants
@hkaiser
Copy link
Member

commented May 29, 2016

  • apply_helper
  • put_parcel

This should solve the stack-overflows which are assumed to cause problems like reported in #2171

Spawning operation on new thread if remaining stack space becomes too…
… small

- apply_helper
- put_parcel

This should solve the stack-overflows which are assumed to cause problems like reported in #2171

@hkaiser hkaiser added this to the 0.9.12 milestone May 29, 2016

}

async_work = remaining_stack < (8 * HPX_THREADS_STACK_OVERHEAD);
#endif

This comment has been minimized.

Copy link
@sithhell

sithhell May 30, 2016

Member

Shouldn't we fall back to recursion count if the stack pointer functionality isn't there? Similar to what is done here: https://github.com/STEllAR-GROUP/hpx/blob/master/hpx/lcos/detail/future_data.hpp#L372

This comment has been minimized.

Copy link
@hkaiser

hkaiser May 30, 2016

Author Member

Recursion of what? I was not sure what counts as a recursion here.

This comment has been minimized.

Copy link
@sithhell

sithhell May 30, 2016

Member

You are right ... the continuation recursion count might not make sense at all in that context.

@@ -116,39 +115,78 @@ namespace hpx { namespace applier { namespace detail
}
};

///////////////////////////////////////////////////////////////////////////
HPX_FORCEINLINE bool needs_to_execute_asynchronously()

This comment has been minimized.

Copy link
@sithhell

sithhell May 30, 2016

Member

Would it make sense to put this function into it's own header? We use the same functionality at three different places now. This would reduce code duplication and sources for errors.

This comment has been minimized.

Copy link
@hkaiser

hkaiser May 30, 2016

Author Member

Not quite, I left those separate as I think we will end up with different criteria for deciding whether we have sufficient stack space.

This comment has been minimized.

Copy link
@sithhell

sithhell May 30, 2016

Member

Which criteria are you thinking about? Couldn't we just have a defaulted (to 8 * HPX_THREADS_STACK_OVERHEAD) argument? What else could be different?

This comment has been minimized.

Copy link
@hkaiser

hkaiser May 30, 2016

Author Member

Yah, it's probably mainly the amount of stack which has to be available for going ahead synchronously. I'll factor out the function.

@hkaiser hkaiser force-pushed the fixing_2171 branch from 8d1557f to ad14524 May 30, 2016

@sithhell

This comment has been minimized.

Copy link
Member

commented May 31, 2016

LGTM!

@hkaiser hkaiser merged commit 58f76b2 into master Jun 1, 2016

1 check passed

ci/circleci Your tests passed on CircleCI!
Details

@hkaiser hkaiser deleted the fixing_2171 branch Jun 1, 2016

@sithhell sithhell referenced this pull request Jun 6, 2016

Merged

Fix hangs #2200

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.