trace() and testing asynchronous callbacks and concurrency

Joerg-Cyril.Hoehle at t-systems.com Joerg-Cyril.Hoehle at t-systems.com
Wed Jan 27 04:24:08 CST 2010


Hi,

I'm seeking advice and ideas about 2 issues:

A) I've added trace() output to a callback function. On a
dual-core XP box, output comes out like follows:
  mmidiid.ci:56.: Ccall:bac7k! 9m: sTg=e3c9s 1t2 fef58 a0
  iled: Message 3c9 from command midiStreamOut
which is a mixture of characters from:
  midi.c:56: Callback! msg=3c9... and
  midi.c:79:Test fa[iled...]

What can I do if trace() may produce such valuable output that I
don't want to miss it from a test log, i.e. I don't want
to remove the trace() entirely?

BTW, this is interesting on its own because it proves that at least the
MM_MOM_DONE (3c9) callback from midiStreamOut may be sent from another
thread than the application's.


B) How to sanely test the effects of callbacks yet be
compatible with ok() and broken()?
The reason is that some callbacks are not invoked on w2k. They are on XP.
If you look at my test_notification() pattern in winmm/tests/mci.c,
you'll notice that while it's barely useable with ok(), it does not work
together with broken().

What I need to express is
rc = midiXYZ()
ok(callback=MM_MOM_3c9 || broken(callback=none) /* w2k and presumably w9x */)

Yet this is incomplete: Not only must the type be tested (MM_MOM_xyz), but also
the parameters and other slots of the MSG (e.g. msg.hwnd) or callback function
(e.g. midihdr).  That's why I created the function test_notification(x,y,z)
back then for MCI, which does all that.

A possibility may be
get_notification() /* retrieve data from callback function or message */
ok(cb_type == MM_MOM_3c9 || broken(cb_type==0))
if (cb_type==MM_MOM_3c9) {
    if (cb_type==CALLBACK_WINDOW || THREAD) {
        ok(cb_hwnd  == hwnd);
    }
    ok(cb_parm1 == mhdr && cb_parm2 == 0);
    ...}
This is getting too verbose fast.
Any better suggestion?

Thanks for your help,
 Jörg Höhle



More information about the wine-devel mailing list