Paul Gofman (@gofman) commented about dlls/ntdll/unix/server.c:
result->async_io.total = info; /* the server will pass us NULL if a call failed synchronously */ set_async_iosb( call->async_io.sb, result->async_io.status, info );
//TRACE("call->async_io.sb %#llx, status %#x, result->async_io.status %#x\n", call->async_io.sb, status, result->async_io.status);/* if ( call->async_io.sb && !in_wow64_call()) *//* { *//* IO_STATUS_BLOCK *io = wine_server_get_ptr( call->async_io.sb ); *//* TRACE( "&io->Status %p, io->Status %#x\n", &io->Status, io->Status ); *//* } */if (status == STATUS_CANCELLED)
What is the rationale behind handling STATUS_CANCELLED on the client and separately relaying to the server? In any case, the server gets IOSB result relayed back from system APC processing. Regardless, the server knows async canceled status explicitly. In either case, should not it stick to its explicit knowledge that async is canceled (and not rely to STATUS_CANCELED in iosb which might be set arbitrary by the app in IOSB or driver under some different circumstances)? I suppose one or another way, all that logic should be contained inside wineserver and it should be signaling cancel wait object based on its knowledge that async canceled (would it be the explicit flag as it is now or derived in some other way, like checking the canceled async queue, as the flag seems to be going away in previous patches for some reason).