[PATCH 1/3] server: Return successful select result separately from select request result.

[Jacek Caban]

Allows returning to caller arbitrary status including values that would 
be otherwise have special meaning for client.

Signed-off-by: Jacek Caban 
---
  dlls/ntdll/server.c | 10 ++++++----
  dlls/ntdll/sync.c   |  9 ++++++---
  server/protocol.def |  5 +++++
  server/thread.c     | 37 +++++++++++++++++++++----------------
  server/trace.c      |  2 +-
  5 files changed, 39 insertions(+), 24 deletions(-)

[Alexandre Julliard]

Jacek Caban  writes:
> Allows returning to caller arbitrary status including values that
> would be otherwise have special meaning for client.

That series doesn't look very nice. Do we really need all that
complexity?

It seems to me it would be easier to use some different status values
just for the async case, and leave the rest of the code alone.

[Jacek Caban]

On 5/13/19 8:14 PM, Alexandre Julliard wrote:
> Jacek Caban  writes:
> > Allows returning to caller arbitrary status including values that
> > would be otherwise have special meaning for client.
>
> That series doesn't look very nice. Do we really need all that
> complexity?
>
> It seems to me it would be easier to use some different status values
> just for the async case, and leave the rest of the code alone.

Part of my consideration was that the problem is not limited to pending 
return. Errors reported by IRP dispatcher may also need to return status 
code without touching status block. select complication is indeed not 
pretty, but server_*_file part seems nice. I attached patches 
implementing pending blocking for the context.

I also attached tests showing possible further problem with errors. I 
didn't implement the error behaviour and I'm not aware of an application 
that needs this, but on top of that series it should not need more 
protocol changes. Anyway, I will look for less invasive solution if you 
prefer.

Thanks,

Jacek

[Marvin]

Hi,

While running your changed tests, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?

Full results can be found at:
https://testbot.winehq.org/JobDetails.pl?Key=52212

Your paranoid android.

=== build (build log) ===

error: patch failed: server/file.h:192
Task: Patch failed to apply

=== debian9 (build log) ===

error: patch failed: server/file.h:192
Task: Patch failed to apply

=== debian9 (build log) ===

error: patch failed: server/file.h:192
Task: Patch failed to apply