https://bugs.winehq.org/show_bug.cgi?id=48291
--- Comment #47 from Zebediah Figura z.figura12@gmail.com --- (In reply to qsniyg from comment #46)
(In reply to Zebediah Figura from comment #45)
You'd need to do IPC without syscalls, which strikes me as pretty much impossible.
Unless you're speaking about another part of wine, IPC would only be used if seccomp cannot be used, which means it shouldn't matter if it uses syscalls or not. The existing implementation could theoretically even be kept, if duplication of code doesn't matter.
You proposed that the implementation of ntdll be moved to wineserver. That's a separate process; how exactly are you proposing we communicate with it? We currently do so via sockets; that's IPC and requires system calls.
(In reply to qsniyg from comment #46)
(In reply to Zebediah Figura from comment #45)
Not to mention that relying on IPC for everything that could involve a system call would be enormously expensive. The degree to which we do already is bad enough.
That's a good point. In _theory_ (part of) the implementation for syscalls could reside somewhere else in the wine source code, and both wineserver and the userspace dlls could access it, so it wouldn't change anything performance-wise if using IPC. This would obviously increase the complexity of both the userspace dlls and wineserver, but I guess it could be a compromise, if it could be properly pulled off.
I'm not sure what you're even proposing here. ntdll runs in a given client process, wineserver runs in a different process. One of these has to execute, say, an NtReadFile() call and the underlying read() call that this probably implies. Making the wineserver do that incurs a lot of overhead no matter how it's done—it inheres just from counting the extra context switches and scheduling.