On Wed Oct 8 13:32:43 2025 +0000, Rémi Bernon wrote:
Yes, you could create it with `create_server_internal_sync` and then use `server_wait_for_object`, but there's no reason to do that here. It's mostly only still useful for the couple of object types for which signal / satisfied logic is complicated (completion waits, asyncs), or which require specific handling of the subsequent wait (debug objects, which need to send/receive thread contexts). And I think we should instead work toward getting rid of those requirements and have everything able to use inproc syncs instead. Here, the sync is already an event-like sync with a simple signaled state, and it can use an inproc sync to save all the extra requests that would be required for the wait operation, and make the wait happen entirely on the client-side / in kernel.
`async_complete_cancel()` is currently called from `async_set_result()`, which is in the server and a step that all asyncs always go through. It doesn't look like moving the whole async "result" handling to the client is something that can be reasonably done in the short term, so I guess my question is whether it seems better to "clarify" that the wait is effectively server-side only by using `server_wait_for_object()` or to return to `NtWaitForSingleObject()` even though that effectively always involves the server.
Maybe there are still advantages to allowing in-proc sync even in this case? I'm going to finish setting up ntsync and tinker a bit with it...