OK, wine made it's first successful RPC's on my box today (yay!)
Now, it's time to do a smidgen of housekeeping, and whip up a test. This is a bit tricky, I have a few open questions, which I will enumerate:
1) It feels like cheating to use the same process as client /and/ server. OTOH, it will be a bit cleaner to do it as such... any thoughts on this? specifically,
1a) Will wedging what is basically a winelib app into my test directory create a problem in the configure/make system? Is there a clean way to make sure I invoke the right winelib .exe.so file (the one in my test directory)?
1b) Are all the process-control API's I will need for this in place? (in particular I should kill off the server in case of a failure... will this be a problem? I guess probably not, or else I'd see a lot more wine's hanging around in my process table.)
1c) If the test fails in the winelib thingy, I have to propagate this back to the test; but relying on RPC for this (aside from being unimplemented ATM) is a catch-22, since error propagation might be broken (hence the need for a test)... I guess I can think of creative solutions to this like putting stupid temp files somewhere. Any better ideas?
1d) Anyone know of a problem with this I haven't thought of yet?
2) Whether I use threads or processes, I need some coordination to happen; I am very concerned about race conditions. I want my tests to run under the most absurd and grueling conditions, with NO race conditions. But I can't wrap my mind around how to avoid them ATM. For example:
2a) Should the rpc.c "real" test be the client or the server? I can imagine races either way. Let's say rpc.c is the client. This isn't so bad at a glance; I invoke the server thread/process, and poll RPC from time to time until it goes active (how I do this is another issue, but I'll think of something). Now I do my magic, and request a shutdown via RPC to the server... but, in two cases there is technically a race: first, while I'm invoking the server, I have to wait for it to start as discussed; second, after I send the Shutdown RPC to the server, I have to actually wait for the process/thread to terminate. In both cases, how long is long enough? What if the tests are running on some absurdly bogged down machine that's simultaneously compiling a matrix of 10,000 different wine's, for example? On the other hand, if I use some really liberal timeout like 30 minutes, then in a failure condition, my test would appear to hang, this isn't so great either. If rpc.c is the server, similar problems exist.
2b-?) uh, I guess I squeezed all of these questions into 2a.
3) MIDL? I still haven't figured out the legal ramifications of using midl-generated code. I'd rather not spend a month working on widl before generating a test... so do I need to code my stubs by hand? Even if I do, they're gonna come out looking more-or-less just like MIDL code... maybe I need to figure out the licensing restrictions on MIDL-generated code myself, but does anyone know offhand, I didn't see any obvious discussion of this on microsoft.com or in the platform sdk.
ugh. thanks for taking the time to read this long-winded post. Any responses, assistance, flames, etc. are appreciated.
2a) Should the rpc.c "real" test be the client or the server? I can imagine races either way. Let's say rpc.c is the client.
Why not let one process start both (client and server). This process could control both and kill them later... ... or have one executable which can act as supervisor, client or server depending on a command line switch. If started without a switch act as supervisor and start itself again twice with different switches...
juergen --- juergen.schmied@debitel.net
On Wednesday 30 October 2002 07:21 am, Greg Turner wrote:
On Monday 28 October 2002 04:56 am, Jürgen Schmied wrote:
2a) Should the rpc.c "real" test be the client or the server? I can imagine races either way. Let's say rpc.c is the client.
Why not let one process start both (client and server). This process could control both and kill them later... ... or have one executable which can act as supervisor, client or server depending on a command line switch. If started without a switch act as supervisor and start itself again twice with different switches...
juergen
juergen.schmied@debitel.net
this is also a possibility, but doesn't this create the need for even more IPC? the big open issue is: how do the test results get back to the actual test program? obviously there are many ways to do it; but doesn't separating things like this just make it harder?
Actually, I was leaning towards the idea of having the test program itself be both client and server... but AFAIK there is no wine-compatible way to fork()..?
Am Mit, 2002-10-30 um 16.43 schrieb Greg Turner:
Actually, I was leaning towards the idea of having the test program itself be both client and server... but AFAIK there is no wine-compatible way to fork()..?
Why don't you just use CreateThread()?
I am doing this for the winsock tests and it works just fine. You can use thread-local storage to keep variables separate.
Martin
On Wednesday 30 October 2002 11:00 am, Martin Wilck wrote:
Am Mit, 2002-10-30 um 16.43 schrieb Greg Turner:
Actually, I was leaning towards the idea of having the test program itself be both client and server... but AFAIK there is no wine-compatible way to fork()..?
Why don't you just use CreateThread()?
I am doing this for the winsock tests and it works just fine. You can use thread-local storage to keep variables separate.
Martin
I need to cross a process boundary. There is per-process storage in rpcrt4 that I don't want shared during my tests. Single-process RPC's are worthy of their own test, however; I probably ought to test both possibilities.
BTW, this is somewhat off-topic, but sometimes the winsock test hangs for me after "make testclean"; ctrl-c and re-running "make test" always works, so I wonder if perhaps there is a race condition tickled by the make processing? Next time (if there is one) that I encounter this, I'll attach a debugger and tell you what I see.
On Wednesday 30 October 2002 12:22 pm, Greg Turner wrote:
BTW, this is somewhat off-topic, but sometimes the winsock test hangs for me after "make testclean"; ctrl-c and re-running "make test" always works, so I wonder if perhaps there is a race condition tickled by the make processing? Next time (if there is one) that I encounter this, I'll attach a debugger and tell you what I see.
this happened to turn up last night. first, i was wrong that this was your winsock test, Martin; it's the http test in dlls/wininet/tests (not sure who owns that code?)
nevertheless, i attached a debugger, here's a trace:
#0 0x4033a0a4 in read () from /lib/libc.so.6 #1 0x40110654 in __JCR_LIST__ () from /var/src/wine/dlls/libntdll.dll.so #2 0x400ccc33 in WaitForMultipleObjectsEx (count=0, handles=0x0, wait_all=0, timeout=100, alertable=0) at ../../scheduler/synchro.c:265 #3 0x400cc989 in Sleep (timeout=100) at ../../scheduler/synchro.c:186 #4 0x40234a43 in winapi_test (flags=268435456) at http.c:139 #5 0x40234f8c in func_http () at http.c:211 #6 0x402354ee in run_test (name=0xbffff7c5 "http.c") at ../../../include/wine/test.h:283 #7 0x402356f4 in main (argc=2, argv=0xbffff638) at ../../../include/wine/test.h:322 #8 0x40234040 in __wine_exe_main () at wininet_test.exe.spec.c:133 #9 0x400c80aa in start_process () at ../../scheduler/process.c:564 #10 0x400ccfa5 in call_on_thread_stack (func=0x400c7dde) at ../../scheduler/sysdeps.c:112 (gdb)
after this, as predicted above, "killall wine; killall wineserver; make test" succeeded. "rm dlls/wininet/tests/http.ok; make test" also succeeds. As soon as I do "make testclean && make test," it hangs again. To whomever wants to tackle this, let me know if there's more info I should give; the behvior is more-or-less repeatable on my box.
Yes, there's a race condition, although it looks like you've got a different bit of NTDLL failing.
See: http://bugs.winehq.com/show_bug.cgi?id=970
Cheers,
Paul.
On Thu, 31 Oct 2002, Greg Turner wrote:
On Wednesday 30 October 2002 12:22 pm, Greg Turner wrote:
BTW, this is somewhat off-topic, but sometimes the winsock test hangs for me after "make testclean"; ctrl-c and re-running "make test" always works, so I wonder if perhaps there is a race condition tickled by the make processing? Next time (if there is one) that I encounter this, I'll attach a debugger and tell you what I see.
this happened to turn up last night. first, i was wrong that this was your winsock test, Martin; it's the http test in dlls/wininet/tests (not sure who owns that code?)
nevertheless, i attached a debugger, here's a trace:
#0 0x4033a0a4 in read () from /lib/libc.so.6 #1 0x40110654 in __JCR_LIST__ () from /var/src/wine/dlls/libntdll.dll.so #2 0x400ccc33 in WaitForMultipleObjectsEx (count=0, handles=0x0, wait_all=0, timeout=100, alertable=0) at ../../scheduler/synchro.c:265 #3 0x400cc989 in Sleep (timeout=100) at ../../scheduler/synchro.c:186 #4 0x40234a43 in winapi_test (flags=268435456) at http.c:139 #5 0x40234f8c in func_http () at http.c:211 #6 0x402354ee in run_test (name=0xbffff7c5 "http.c") at ../../../include/wine/test.h:283 #7 0x402356f4 in main (argc=2, argv=0xbffff638) at ../../../include/wine/test.h:322 #8 0x40234040 in __wine_exe_main () at wininet_test.exe.spec.c:133 #9 0x400c80aa in start_process () at ../../scheduler/process.c:564 #10 0x400ccfa5 in call_on_thread_stack (func=0x400c7dde) at ../../scheduler/sysdeps.c:112 (gdb)
after this, as predicted above, "killall wine; killall wineserver; make test" succeeded. "rm dlls/wininet/tests/http.ok; make test" also succeeds. As soon as I do "make testclean && make test," it hangs again. To whomever wants to tackle this, let me know if there's more info I should give; the behvior is more-or-less repeatable on my box.
-- gmt
"The purpose of government is to rein in the rights of the people" --President Bill Clinton, MTV interview, 1993
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Particle Physics (Theory & Experimental) Groups Paul Millar Department of Physics and Astronomy paulm@astro.gla.ac.uk University of Glasgow paulm@physics.gla.ac.uk Glasgow, G12 8QQ, Scotland http://www.astro.gla.ac.uk/users/paulm +44 (0)141 330 4717 A54C A9FC 6A77 1664 2E4E 90E3 FFD2 704B BF0F 03E9 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-
Greg Turner -
Jürgen Schmied -
Martin Wilck -
Paul Millar