Re: [2/5] include/wine/test.h: Report child process failures using shared memory.
Dmitry Timoshkov <dmitry(a)baikal.ru> writes:
Alexandre Julliard <julliard(a)winehq.org> wrote:
As far as I can see ExitProcess returns 'failures' as the child process exit code, but variable 'failures' is not visible from the tests. Do you have a suggestion how to fix that?
You need to report the status a different way. For instance you could store it in a file.
How does this one look like? (In theory this approach could be used to transfer other child process information to the parent).
Something like this would work, but it should be done in the test that needs it, not in the generic code. -- Alexandre Julliard julliard(a)winehq.org
Alexandre Julliard <julliard(a)winehq.org> wrote:
As far as I can see ExitProcess returns 'failures' as the child process exit code, but variable 'failures' is not visible from the tests. Do you have a suggestion how to fix that?
You need to report the status a different way. For instance you could store it in a file.
How does this one look like? (In theory this approach could be used to transfer other child process information to the parent).
Something like this would work, but it should be done in the test that needs it, not in the generic code.
What's wrong with using this code for all tests? And sorry, I don't see how I could utilize this in the ExitProcess test since I need to call ExitProcess with a not zero exit code and that code is currently used to report number of child failures to parent. -- Dmitry.
Dmitry Timoshkov <dmitry(a)baikal.ru> writes:
Alexandre Julliard <julliard(a)winehq.org> wrote:
As far as I can see ExitProcess returns 'failures' as the child process exit code, but variable 'failures' is not visible from the tests. Do you have a suggestion how to fix that?
You need to report the status a different way. For instance you could store it in a file.
How does this one look like? (In theory this approach could be used to transfer other child process information to the parent).
Something like this would work, but it should be done in the test that needs it, not in the generic code.
What's wrong with using this code for all tests? And sorry, I don't see how I could utilize this in the ExitProcess test since I need to call ExitProcess with a not zero exit code and that code is currently used to report number of child failures to parent.
The standard test code should be kept as simple as possible. Also creating extra mappings can potentially influence other tests. In your parent process you can use whatever mechanism you want to report failures, you don't have to use the child exit code. -- Alexandre Julliard julliard(a)winehq.org
Alexandre Julliard <julliard(a)winehq.org> wrote:
The standard test code should be kept as simple as possible. Also creating extra mappings can potentially influence other tests.
I still think that this code can be used on a general base, and if needed mapping name could be made more unlikely to dulicate. Especially since it's already written and tested quite a bit.
In your parent process you can use whatever mechanism you want to report failures, you don't have to use the child exit code.
If you mean avoiding to use winetest_wait_child_process() then yes, I can certainly do that. -- Dmitry.
Dmitry Timoshkov <dmitry(a)baikal.ru> writes:
Alexandre Julliard <julliard(a)winehq.org> wrote:
The standard test code should be kept as simple as possible. Also creating extra mappings can potentially influence other tests.
I still think that this code can be used on a general base, and if needed mapping name could be made more unlikely to dulicate. Especially since it's already written and tested quite a bit.
The right way is to duplicate the code into the tests that need it, until you can demonstrate that there are enough tests using it to justify refactoring it into the standard code. -- Alexandre Julliard julliard(a)winehq.org
participants (2)
-
Alexandre Julliard -
Dmitry Timoshkov