Dear Alexandre,
- separate cleanly between async scheduling and file IO related issues,
- make the API compatible with other types of async requests (e.g. for sockets),
- remove exports of async IO related functions for DLL separation.
You cannot add private headers to work around the dll separation restrictions, this only hides the dependencies between dlls it doesn't solve them... I have applied the patch for now, but the async.h file will have to go away eventually (or the functionality will need to be "officially" exported from ntdll).
What would be the correct solution, then? If I understand you right, each DLL that uses async IO must have its own implementation of async calls, i.e. not rely on anything implemented in ntdll except for the officially exported windows functions.
To achieve that, we can put functionally equivalent code into each DLL's sources, or we can provide a header that defines only static functions - as the first version of my patch did. That approach has the advantage that we won't have to repeat the same code in source files of different DLLs. What would be wrong with that?
The second version I sent (with check_async_list called automatically from call_apcs) re-introduces a hidden dependency on ntdll - obviously async calls from other DLLs won't work anymore if a native ntdll is used. That may be a step back. Still I cannot see a problem with the "static-only" header I used in the first version - can you explain that to me?
Martin
PS does anybody have an idea how Windows itself handles this, i.e. if the async calls in e.g. the Winsock API call ntdll functions internally? After all, it seems to be legitimate to mix ReadFile() and WSARecv() calls on sockets, although it would certainly be bad programming style. If we could only conceive of a way to implement async calls only on top of "official" windows functions...