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.