We *really* need a development model change !

[Andriy Palamarchuk]

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 at 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