Meziprocesová komunikace a velikost handle

[pepak]

Mám několik aplikací, které spolu chtějí komunikovat. Pro hromadnou komunikaci se jako ideální jeví memory-mapped file, protože ten vidí všichni stejně. Jenže občas potřebuju i komunikaci 1:1, a na to se mi MMF nelíbí. Tak jsem si myslel, že si případně mohla do toho společného MMF každá aplikace zapsat do nějakého pole handle svého hlavního okna (a při skončení tohle handle nahradit INVALID_HANDLE_VALUE, aby se poznalo, že s touhle aplikací už se komunikovat nemá). Zájemce o komunikaci by si z pole vytáhl handle adresáta a poslal mu běžnou zprávu (PostMessage, SendMessage).

Jenže mě napadá, a jak to bude fungovat, když část aplikací bude 32bitová a část 64bitová? Já samozřejmě to pole můžu udělat s 64bitovými položkami, takže se mi tam vejdou handly obou typů aplikací, jenže co si počne 32bitová aplikace s 64bitovým handlem (když pro PostMessage bude muset mít 32bitový handle) a naopak?

A když to rozšířím, dejme tomu, že nějak vyřeším získání handle okna. Když dojde na lámání chleba a já budu chtít poslat zprávu, tak narazím na to, že i wParam a lParam jsou jinak velké. Když pošlu zprávu z 32bitové aplikace do 64bitové, tak mi to systém, předpokládám, doplní nulami, takže o nic nejde, ale co se stane, když pošlu zprávu z 64bitové aplikace do 32bitové? To to systém ořízne, nebo poslání zprávy selže, nebo jak se s tím systém vypořádá?

[Vrtule]

Já jsem nikdy moc nepřišel na chuť posílání zpráv jako mechanismu pro penášení dat mezi procesy. Vždycky jsem se uchyloval k paměťově mapovanému souboru (s příslušnými synch. primitivy (semafory, eventy)), nebo používal roury (to obvykle v případě, že rodičovský proces potřeboval komunikovat s dítětem).

Co jsem ale pochopil z dokumentace, u tzv. systémových zpráv (kód 0 až WM_USER - 1) si jádro problémy vznikající z rozdílů velikostí pointerů v 32bitových a 64bitových aplikací řeší sám. Tedy pokud je součástí zprávy nějaká struktura, na kteoru například ukazuje LPARAM, tak se ta struktura kopíruje a LPARAM rozumně mění tak, aby se vešel do příslušné velikosti pointeru. V dokumentaci navíc doporučují WM_COPYDATA jako jedinou zprávu vhodnou pro přenášení dat. Ale moc se zprávami nezabývám, takže můžu být dost mimo mísu.

Co se týče velikosti handle: nevím, jak u handlů oken a jiných GDI/USER objektů, ale v případě objektů jádra (paměťově mapované soubory, synchronizační primitiva, soubory aj.) jsem handle, jehož hodnota by se nevešla do 32 bitů, ještě neviděl. Dříve (Windows XP) platil limit maximálního počtu handle cca 2^24 pro každou aplikaci (tabulka handle více nepojala). Nevím, zda je tento limit zachován i v novějších Windows. Handle se obvykle používá jako index do nějaké datové struktury v jádře, a pokud tato datová struktura není nějak moc členitá (něco na způsob mnohaúrovňového stránkování), tak hodnota handle nikdy vysoká nebude.

Ono vůbec je třeba zajímavé se podívat na identifikační čísla procesů (PID) a vláken (TID). Windows API je prezentuje jako hodnoty typu DWORD (32bitová celá čísla), ale v jádře se pro ně používá typ HANDLE (tedy pointer). Zdá se, že možné problémy s velikostí zatím nikomu nepřekážejí. Čísla PID a TID snad ještě pořád jsou uložena v jakési tabulce handle, takže to handle opravdu jsou.