RPC test code?

[Greg Turner]

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.

-- 
gmt

"The purpose of government is to rein in the rights of the people"
 --President Bill Clinton, MTV interview, 1993