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

Nested exception_list in parallel algorithm. #2817

Open
taeguk opened this Issue Aug 11, 2017 · 6 comments

Comments

Projects
None yet
3 participants
@taeguk
Member

taeguk commented Aug 11, 2017

Is nested exception_list admitted in parallel algorithm?

return hpx::dataflow(
[last](hpx::future<RandomIt> && left,
hpx::future<RandomIt> && right) -> RandomIt
{
if (left.has_exception() || right.has_exception())
{
std::list<std::exception_ptr> errors;
if (left.has_exception())
errors.push_back(left.get_exception_ptr());
if (right.has_exception())
errors.push_back(right.get_exception_ptr());
throw exception_list(std::move(errors));
}
return last;
},
std::move(left), std::move(right));

For example, in case of parallel::sort, there is nested exception_list.
Because of recursive implementation of the algorithm, exception_lists are inside of an exception_list and this structure is repeated and nested.
Is this okay? Or is this problem?

@hkaiser

This comment has been minimized.

Show comment
Hide comment
@hkaiser

hkaiser Aug 11, 2017

Member

This shouldn't be an issue. Our exception_list was designed to support that. Could you try to construct a test which verifies this?

Member

hkaiser commented Aug 11, 2017

This shouldn't be an issue. Our exception_list was designed to support that. Could you try to construct a test which verifies this?

@taeguk

This comment has been minimized.

Show comment
Hide comment
@taeguk

taeguk Aug 11, 2017

Member

@hkaiser I mean that currently nested exception_list seems to be not useful.
For example, when I call exception_list::get_message(), it seems to 'just' iterate to exceptions that the exception_list has.
I think that traversal to nested exception_list is correct.
In fact, I don't know exactly what is right.
Is there no mention about this in p0322r0?

Member

taeguk commented Aug 11, 2017

@hkaiser I mean that currently nested exception_list seems to be not useful.
For example, when I call exception_list::get_message(), it seems to 'just' iterate to exceptions that the exception_list has.
I think that traversal to nested exception_list is correct.
In fact, I don't know exactly what is right.
Is there no mention about this in p0322r0?

@hkaiser

This comment has been minimized.

Show comment
Hide comment
@hkaiser

hkaiser Aug 11, 2017

Member

For example, when I call exception_list::get_message(), it seems to 'just' iterate to exceptions that the exception_list has.

What else would you like to see?

Is there no mention about this in p0322r0?

They ditched exception handling altogether. Any exception thrown will cause std::terminate to be called (for the std execution policies, other execution policies are free to do whatever they want).

Member

hkaiser commented Aug 11, 2017

For example, when I call exception_list::get_message(), it seems to 'just' iterate to exceptions that the exception_list has.

What else would you like to see?

Is there no mention about this in p0322r0?

They ditched exception handling altogether. Any exception thrown will cause std::terminate to be called (for the std execution policies, other execution policies are free to do whatever they want).

@taeguk

This comment has been minimized.

Show comment
Hide comment
@taeguk

taeguk Aug 12, 2017

Member

@hkaiser
image
("EL" means 'exception_list', and "E" means normal exception.)
Like above, utilizing nested exception_list is difficult because of its tree structure.
So, I think avoiding nested exception_list may be better.
And currently, exception_list::get_message() can't process nested exception_list exactly because exception_list::get_message() just iterates in only first level of that tree structure.
In fact, this problem from nested exception_list can be not such important. I wanted to just reveal the issue to public space because an user can misunderstand like exception_list is not nested.
How do you think about it? Should this be resolved? Or is leaving this okay?

They ditched exception handling altogether. Any exception thrown will cause std::terminate to be called (for the std execution policies, other execution policies are free to do whatever they want).

What plan do you have about it? Will you follow their way? Or Will you keep our way?

Member

taeguk commented Aug 12, 2017

@hkaiser
image
("EL" means 'exception_list', and "E" means normal exception.)
Like above, utilizing nested exception_list is difficult because of its tree structure.
So, I think avoiding nested exception_list may be better.
And currently, exception_list::get_message() can't process nested exception_list exactly because exception_list::get_message() just iterates in only first level of that tree structure.
In fact, this problem from nested exception_list can be not such important. I wanted to just reveal the issue to public space because an user can misunderstand like exception_list is not nested.
How do you think about it? Should this be resolved? Or is leaving this okay?

They ditched exception handling altogether. Any exception thrown will cause std::terminate to be called (for the std execution policies, other execution policies are free to do whatever they want).

What plan do you have about it? Will you follow their way? Or Will you keep our way?

@hkaiser

This comment has been minimized.

Show comment
Hide comment
@hkaiser

hkaiser Aug 12, 2017

Member

What plan do you have about it? Will you follow their way? Or Will you keep our way?

For now I'd like to keep it as we have it as calling std::terminate just because of an exception being thrown is not an option, in my opinion.

Member

hkaiser commented Aug 12, 2017

What plan do you have about it? Will you follow their way? Or Will you keep our way?

For now I'd like to keep it as we have it as calling std::terminate just because of an exception being thrown is not an option, in my opinion.

@hkaiser

This comment has been minimized.

Show comment
Hide comment
@hkaiser

hkaiser Aug 12, 2017

Member

And currently, exception_list::get_message() can't process nested exception_list exactly because exception_list::get_message() just iterates in only first level of that tree structure.

That's correct. The user however can easily iterate over the tree using the public interface.

Member

hkaiser commented Aug 12, 2017

And currently, exception_list::get_message() can't process nested exception_list exactly because exception_list::get_message() just iterates in only first level of that tree structure.

That's correct. The user however can easily iterate over the tree using the public interface.

@msimberg msimberg removed this from the 1.1.0 milestone Dec 5, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment