Hmm, I don't see my post in wine-devel. Alexandre, did I send the message directly to you? If yes, could you, please, forward to the mailing list? Thank you.
Alexandre Julliard wrote:
Andriy Palamarchuk apa3a@yahoo.com writes:
Simple tests work fine. Problems start when I try to use multithreaded Wine tests. In one case the framework stucks on reading from pipe. Other code layouts have other issues. The cause may be in incorrect pipes handling, multi-process tests handling or interaction with Wine thread implementation.
I'm not sure if this is what happens, but if two threads try to send results down the same pipe you'll have problems.
I think there is no competition for the pipe. New pipe is opened for each test. It looks like not all handles are closed to the write side of the pipe and read hangs. Can it happen because the handle is inherited to wineserver?
You need explicit threading support in the framework if you want to create threads (the Perl framework doesn't support threads either at this point, so if your test works there it's by pure luck).
:-( I need more than one thread to catch message on system parameter value change.
Another potential problem is that the fork() option of the framework is going to cause major breakage. You cannot use fork inside a Winelib app.
I really like memory protection which is provided by "fork()". We are going to need it (e.g. for TODO tests) :-/ The framework can be used in forkless mode, however we still need to remove that piping stuff.
Can we have the same advantages by using two-stage launching process? The first part coordinates everything and starts each test with "exec". Such implementation is less efficient but much more portable.
And in any case I don't think a GPLed framework is appropriate for Wine.
a) this is license not for Wine, but for Wine testing application. From my point of view GPL is very appropriate in this case. Any other OS projects, using the test application will have to contribute the changes back. On other hand the license won't hurt any commercial application because nobody will make business on it.
b) on the Check mailing list I saw request to change license to less restrictive one.
The main developer of the framework took into account this request. I also asked for less restrictive license, posted a couple bug reports, but have not had any feedback yet.
I have an idea for compromise - let's use both - Perl and C tests. Perl module Test::Harness can be used to manage both types of the tests. C test application can print feedback information in format Test::Harness needs. A library can be created for this. This gives all the advantages of both tools and choice, do not impose big constraints on developers. Test::Harness is very mature framework and has clearly defined interface.
I'm still for keeping all the tests as separate application. It is very easy to create test hierarchy for tests application if you want to have subsets of the tests.
Andriy Palamarchuk