Opened on 12/02/2016 at 06:03:46 PM
Closed on 07/31/2017 at 02:37:29 PM
#4688 closed change (fixed)
Get rid of long (forever) blocking operations in tests
| Reported by: | sergz | Assignee: | |
|---|---|---|---|
| Priority: | P3 | Milestone: | |
| Module: | Libadblockplus | Keywords: | |
| Cc: | fhd, oleksandr, asmirnov, eric@… | Blocked By: | |
| Blocking: | #3595, #5198 | Platform: | Unknown / Cross platform |
| Ready: | no | Confidential: | no |
| Tester: | Unknown | Verified working: | no |
| Review URL(s): |
https://codereview.adblockplus.org/29367522/ |
||
Description
Background
In tests we have many Lazy* classes which block a background thread. To achieve #3595 we need to make changes to have a way to finish all background threads withing a reasonable time span.
What to change
One possible way to achieve it is to introduce and mock in tests asynchronous interfaces for WebRequest, FileSystem and for timers. Implementation of this interfaces should work with threads or with some asynchronous API and to avoid race conditions the lifetime of them should be managed by JsEngine.
Attachments (0)
Change History (7)
comment:1 Changed on 12/14/2016 at 08:55:24 PM by eric@adblockplus.org
- Review URL(s) modified (diff)
- Status changed from new to reviewing
comment:2 Changed on 12/14/2016 at 08:57:50 PM by eric@adblockplus.org
comment:3 Changed on 04/28/2017 at 08:56:43 AM by sergz
- Blocking 5198 added
comment:5 Changed on 05/11/2017 at 09:49:33 AM by abpbot
A commit referencing this issue has landed:
Issue 4688 - stop using of LazyWebRequest in tests/UpdateCheck.cpp
comment:6 Changed on 05/26/2017 at 01:54:29 PM by sergz
- Blocking 3593 removed
comment:7 Changed on 07/31/2017 at 02:37:29 PM by sergz
- Resolution set to fixed
- Status changed from reviewing to closed
Basically there are no "long (forever) blocking operations in tests", so the issue can be closed.
The solution in https://codereview.adblockplus.org/29367522/ is to explicitly block on a condition variable where the infinite loop once was, then to unblock it in a TearDown() function, after the test body has completed. This preserves the existing test behavior insofar as the test body is concerned, but improves the overall performance by allowing those threads to finish.