[PATCH 4/5] server: Added server side mamed pipe read and write implementation and use it for message mode pipes.

[Jacek Caban]

On 28.02.2017 15:12, Alexandre Julliard wrote:
> Sebastian Lackner <sebastian at fds-team.de> writes:
>
>> I don't think write_process_memory is the right way to do it. This function
>> also has a lot of overhead, like suspending the thread, or if /proc is not
>> available reading/writing is done in chunks of sizeof(long). I'm pretty sure
>> it would be faster to just transfer back the result with the same wineserver
>> call. Also please note that the client side already adds a reply buffer,
>> so the changes would mostly be on the server side.
> Agreed. write_process_memory has many issues, and should only be used
> for debugging APIs. We don't want to make it a required part of the
> server protocol.


I never meant this to be required, we could still do everything without
it using APCs. I also never meant it to be part of server protocol
itself. I imagined it to be used instead of APCs in some cases (like
setting IO_STATUS_BLOCK bytes, possibly more for data in read/ioctl) to
avoid round-trips, falling back to APCs in case of any error or other
problem.


Back to the current patch, it just uses currently available mechanisms
to achieve the task and it seems to work well. As I described earlier, I
could implement that without APCs for immediate result, but we would
still need some notification to server that data has been completely
transferred. If we want to do it that way, the cleanest solution IMO
would be a new server call done by clients in server_*_file() functions
called for immediate results after setting iosb fields and receiving
data. Would you prefer that?


Thanks,
Jacek