Dmitry Timoshkov dmitry@baikal.ru wrote:
With minor clean ups and with increased timeout to wait for server termination to please some really slow VMs (that allowed to remove broken() statements).
It would be helpful to provide some feedback and explain the 'pending' state of the patch which adds a test.
Dmitry Timoshkov dmitry@baikal.ru writes:
Dmitry Timoshkov dmitry@baikal.ru wrote:
With minor clean ups and with increased timeout to wait for server termination to please some really slow VMs (that allowed to remove broken() statements).
It would be helpful to provide some feedback and explain the 'pending' state of the patch which adds a test.
It seems to be awfully complicated. In particular I don't think you need a shared mapping plus a pipe plus a mutex just to log tracing output. Redefining standard macros is also not a good idea.
Alexandre Julliard julliard@winehq.org wrote:
It seems to be awfully complicated. In particular I don't think you need a shared mapping plus a pipe plus a mutex just to log tracing output. Redefining standard macros is also not a good idea.
Launching the server in responce to say CoCreateInstance is out of our control, happens behind the scene, and the server runs in its own console, so it's impossible make a simple redirection by passing in/out handles to CreateProcess. So using a pipe and a passing its write end via shared memory seems like an obvious solution. Without a mutex client and server output is messed up under Windows. Redefining trace allows to write to the pipe in the server and synchronize server output on the client side. If you have a suggestion how to simplify all of this please let me know.
Dmitry Timoshkov dmitry@baikal.ru wrote:
Alexandre Julliard julliard@winehq.org wrote:
It seems to be awfully complicated. In particular I don't think you need a shared mapping plus a pipe plus a mutex just to log tracing output. Redefining standard macros is also not a good idea.
Launching the server in responce to say CoCreateInstance is out of our control, happens behind the scene, and the server runs in its own console, so it's impossible make a simple redirection by passing in/out handles to CreateProcess. So using a pipe and a passing its write end via shared memory seems like an obvious solution. Without a mutex client and server output is messed up under Windows. Redefining trace allows to write to the pipe in the server and synchronize server output on the client side.
Did my explanation help with understanding the reasons behind the test implementation details?
If you have a suggestion how to simplify all of this please let me know.
It's pretty hard to make any progress without a reponse.
Dmitry Timoshkov dmitry@baikal.ru writes:
Dmitry Timoshkov dmitry@baikal.ru wrote:
Alexandre Julliard julliard@winehq.org wrote:
It seems to be awfully complicated. In particular I don't think you need a shared mapping plus a pipe plus a mutex just to log tracing output. Redefining standard macros is also not a good idea.
Launching the server in responce to say CoCreateInstance is out of our control, happens behind the scene, and the server runs in its own console, so it's impossible make a simple redirection by passing in/out handles to CreateProcess. So using a pipe and a passing its write end via shared memory seems like an obvious solution. Without a mutex client and server output is messed up under Windows. Redefining trace allows to write to the pipe in the server and synchronize server output on the client side.
Did my explanation help with understanding the reasons behind the test implementation details?
If you have a suggestion how to simplify all of this please let me know.
It's pretty hard to make any progress without a reponse.
The easy way is to not print traces in the server, you shouldn't need that once your test is working. But I'm sure you can find other ways, like using a file in line-buffered mode or things like that. Think about it some more.
Alexandre Julliard julliard@winehq.org wrote:
Launching the server in responce to say CoCreateInstance is out of our control, happens behind the scene, and the server runs in its own console, so it's impossible make a simple redirection by passing in/out handles to CreateProcess. So using a pipe and a passing its write end via shared memory seems like an obvious solution. Without a mutex client and server output is messed up under Windows. Redefining trace allows to write to the pipe in the server and synchronize server output on the client side.
Did my explanation help with understanding the reasons behind the test implementation details?
If you have a suggestion how to simplify all of this please let me know.
It's pretty hard to make any progress without a reponse.
The easy way is to not print traces in the server, you shouldn't need that once your test is working.
The whole complexity of the test is because I really need to see what actions on the server side a client request does produce. That's the actual reason of the test, without it the test doesn't make sense. I need to see output of client and server in order to see why a pretty complex client/ server COM application fails to connect to its components. My test shows that for instance CoCreateInstance on the client side leads to interface queries on the server side from the class factory instead of the object, without my test I wouldn't figure that out.
But I'm sure you can find other ways, like using a file in line-buffered mode or things like that. Think about it some more.
That would help with avoding a mutex, but mutex is a tiny part of the test.
Dmitry Timoshkov dmitry@baikal.ru writes:
Alexandre Julliard julliard@winehq.org wrote:
Launching the server in responce to say CoCreateInstance is out of our control, happens behind the scene, and the server runs in its own console, so it's impossible make a simple redirection by passing in/out handles to CreateProcess. So using a pipe and a passing its write end via shared memory seems like an obvious solution. Without a mutex client and server output is messed up under Windows. Redefining trace allows to write to the pipe in the server and synchronize server output on the client side.
Did my explanation help with understanding the reasons behind the test implementation details?
If you have a suggestion how to simplify all of this please let me know.
It's pretty hard to make any progress without a reponse.
The easy way is to not print traces in the server, you shouldn't need that once your test is working.
The whole complexity of the test is because I really need to see what actions on the server side a client request does produce. That's the actual reason of the test, without it the test doesn't make sense. I need to see output of client and server in order to see why a pretty complex client/ server COM application fails to connect to its components. My test shows that for instance CoCreateInstance on the client side leads to interface queries on the server side from the class factory instead of the object, without my test I wouldn't figure that out.
If it's a test app meant to investigate the behavior, that's fine, but then there's no reason to put it in the test suite.
Just use it to figure out the behavior, and then write a proper test that checks for that behavior using ok() and the like. At that point you don't need traces, because the test is supposed to run unattended and detect failures on its own, without requiring anybody to look at a trace.
Alexandre Julliard julliard@winehq.org wrote:
If it's a test app meant to investigate the behavior, that's fine, but then there's no reason to put it in the test suite.
Just use it to figure out the behavior, and then write a proper test that checks for that behavior using ok() and the like. At that point you don't need traces, because the test is supposed to run unattended and detect failures on its own, without requiring anybody to look at a trace.
My intention was to make the test look like a user32 message test at some point, and even in its current state it already can help other developers. At the moment there is no ole32 tests with a server running in a separate process, so this test would be a good start. I already have other tests which show problems in the client interacting with local server using an in-process handler, but without an initial test accepted it's impossible to add other tests.
-
Alexandre Julliard -
Dmitry Timoshkov