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

Thread exception #496

Merged
merged 16 commits into from
Oct 4, 2022
Merged

Thread exception #496

merged 16 commits into from
Oct 4, 2022

Conversation

mgautierfr
Copy link
Collaborator

@mgautierfr mgautierfr commented Feb 10, 2021

This is a draft PR, just to track the branch. Now ready to review
Fixes #475
Fixes openzim/python-libzim#153

@codecov
Copy link

codecov bot commented Feb 10, 2021

Codecov Report

Base: 84.67% // Head: 84.93% // Increases project coverage by +0.26% 🎉

Coverage data is based on head (b9ac991) compared to base (f26501c).
Patch coverage: 92.98% of modified lines in pull request are covered.

❗ Current head b9ac991 differs from pull request most recent head 76ad28e. Consider uploading reports for the commit 76ad28e to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #496      +/-   ##
==========================================
+ Coverage   84.67%   84.93%   +0.26%     
==========================================
  Files          98       98              
  Lines        4325     4387      +62     
  Branches     1869     1913      +44     
==========================================
+ Hits         3662     3726      +64     
+ Misses        661      660       -1     
+ Partials        2        1       -1     
Impacted Files Coverage Δ
include/zim/writer/creator.h 100.00% <ø> (ø)
src/writer/clusterWorker.cpp 100.00% <ø> (ø)
src/writer/creatordata.h 100.00% <ø> (ø)
src/writer/xapianHandler.h 100.00% <ø> (ø)
src/writer/xapianWorker.cpp 100.00% <ø> (ø)
src/writer/creator.cpp 92.40% <82.85%> (+1.72%) ⬆️
include/zim/error.h 95.34% <93.54%> (-4.66%) ⬇️
src/writer/cluster.cpp 89.56% <100.00%> (+0.37%) ⬆️
src/writer/clusterWorker.h 100.00% <100.00%> (ø)
src/writer/workers.cpp 100.00% <100.00%> (ø)
... and 5 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

@mgautierfr mgautierfr force-pushed the thread_exception branch 2 times, most recently from ff82021 to 29d7104 Compare March 2, 2021 14:14
@kelson42 kelson42 added this to the 7.2.0 milestone Dec 4, 2021
@kelson42
Copy link
Contributor

kelson42 commented Jan 2, 2022

@mgautierfr How much work is needed here to complete this PR?

@mgautierfr mgautierfr marked this pull request as ready for review August 22, 2022 18:10
@mgautierfr
Copy link
Collaborator Author

Tests are failing because we don't wait enough to have the threads "detecting" the error.
(It is enough on my computer, but on the CI).
I wonder how we should handle that. Simply increase the waiting time or simply don't test that subsequent call are failing (finishZimCreation will always detect the error as it waits for all thread to finish, and it would always be tested) ?

@kelson42
Copy link
Contributor

kelson42 commented Aug 22, 2022

@mgautierfr All CI does not pass unfortunately. A header/pragma might be missing ;)

@mgautierfr
Copy link
Collaborator Author

Indeed, it is usleep on Windows.
But usleep is used to wait for the thread and is related to the problem explain in my previous comment
Better wait for a answer to my question and fix it if needed.

Copy link
Collaborator

@veloman-yunkan veloman-yunkan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Some of the errors checked by the new unit test come from ASSERTs that are disabled in a release build. This will lead to bug reports similar to The reader test seems to stuck in a deadlock (zim-testing-suite) for some reason. #670 (see The reader test seems to stuck in a deadlock (zim-testing-suite) for some reason. #670 (comment)).
  2. Handling of errors during ZIM creation must be documented.

test/error_in_creator.cpp Outdated Show resolved Hide resolved
test/error_in_creator.cpp Outdated Show resolved Hide resolved
test/error_in_creator.cpp Outdated Show resolved Hide resolved
test/error_in_creator.cpp Outdated Show resolved Hide resolved
test/error_in_creator.cpp Outdated Show resolved Hide resolved
src/writer/workers.cpp Show resolved Hide resolved
src/writer/workers.cpp Outdated Show resolved Hide resolved
src/writer/creator.cpp Outdated Show resolved Hide resolved
test/error_in_creator.cpp Outdated Show resolved Hide resolved
test/error_in_creator.cpp Show resolved Hide resolved
Copy link
Collaborator

@veloman-yunkan veloman-yunkan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please rebase/fixup and clean the history of this PR for the next (hopefully, final) review

include/zim/error.h Outdated Show resolved Hide resolved
test/error_in_creator.cpp Outdated Show resolved Hide resolved
test/error_in_creator.cpp Outdated Show resolved Hide resolved
@kelson42
Copy link
Contributor

kelson42 commented Sep 5, 2022

@mgautierfr I have updated to comment to say it "fixes #475". Hope this is correct.

@kelson42 kelson42 removed this from the 8.2.0 milestone Sep 5, 2022
test/error_in_creator.cpp Outdated Show resolved Hide resolved
test/error_in_creator.cpp Outdated Show resolved Hide resolved
include/zim/error.h Outdated Show resolved Hide resolved
@veloman-yunkan
Copy link
Collaborator

The concerns raised in the first review have not been addressed:

  1. Some of the errors checked by the new unit test come from ASSERTs that are disabled in a release build. This will lead to bug reports similar to The reader test seems to stuck in a deadlock (zim-testing-suite) for some reason. #670 (see The reader test seems to stuck in a deadlock (zim-testing-suite) for some reason. #670 (comment)).
  2. Handling of errors during ZIM creation must be documented.

@mgautierfr
Copy link
Collaborator Author

Fixed. (I will move the three new commits a bit upper in the git history when rebase-fixup)

Copy link
Collaborator

@veloman-yunkan veloman-yunkan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There were a few typos in the documentation, but I guess you can fix them as you rebase and fixup.

@mgautierfr
Copy link
Collaborator Author

Last push-force split a commit in the history (Make zim::writer::Creator thrown better exception) and create a fixup commit for Introduce CreatorError and InvalidEntry. 4 commits are added at the end. Other commits are unchanged.

Copy link
Collaborator

@veloman-yunkan veloman-yunkan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please fix the only last comment, and rebase-fixup for formal approval to merge.

src/writer/clusterWorker.cpp Outdated Show resolved Hide resolved
Creator is based on API the user have to implement.
If the user create buggy code or throw exception, we must be prepared
to handle them.

The new tests show some use cases (all ?) we must be prepared to handle.
They are not handle now, will be in next commits.
- Introduce a std::exception_ptr slot to be able to pass a exception from
  the worker threads to the main thread.
- Check the slot on each entry point called from the main thread.
- Put the creator "in error" if the exception is set.
- Raise a exception if the creator is in error.
There is no good solution as the value depend of the computer:
- Too long and user wait too much for their tests to run
- Too short and the tests are failing

Let's use a default value and allow user to change the value using a
factor defined in WAIT_TIME_FACTOR_TEST env variable.
Copy link
Collaborator

@veloman-yunkan veloman-yunkan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. You know why I didn't approve.

This avoid code duplication around waiting_task.
This way we can test that it is the expect exception which is thrown and
not another one.
@mgautierfr
Copy link
Collaborator Author

Done :)

@kelson42 kelson42 merged commit 3a9f574 into master Oct 4, 2022
@kelson42 kelson42 deleted the thread_exception branch October 4, 2022 16:20
mgautierfr added a commit that referenced this pull request Nov 30, 2022
* Optimization ofthe first call to `zim::Archive::iterEfficient` (@veloman-yunkan #724)
* Add some documentation to `zim::writer::IndexData` (@mgautierfr #727)
* Correctly catch and rethrow exception thrown in worker threads at creation (@mgautierfr #496 #748)
* Optimization of `Entry::getItem()` (@veloman-yunkan #732)
* Fix declaration of `zim::setICUDataDirectory()` (@MohitMaliFtechiz #733)
* Add `zim::Archive::getMediatCount()` (@mgautierfr #730)
* Make compilaton of examples optional (@mgautierfr #738)
* Add a CI for wasm (@mgautierfr #746)
* Make constructor of SuggestionItem public (@veloman-yunkan #740)
@mgautierfr mgautierfr mentioned this pull request Nov 30, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Exception in getIndexData crashes interpretor Creator should properly handle user-code error
3 participants