We were using bit 1 of RTL_USER_PROCESS_PARAMETERS for two different cases:
- rightfully, as a sign to block ctrl-c events from being processed by
handlers (and by default, terminating the process)
- But this was also used to request for the creation of a new process group.
This patch properly separates the two use cases, by using the
ProcessGroupId field in RTL_USER_PROCESS_PARAMETERS (checked that Win10
behaves as this patch in RtlCreateUserProcess wrt.
RTL_USER_PROCESS_PARAMETERS ProcessGroupId usage input/output).
Introduce process_group_id in startup_info_t and use it to pass it to
server. ProcessGroupId field in RTL_USER_PROCESS_PARAMETERS is now properly
set.
Note: this will change some external behavior.
- before this patch, a child process created with Ctrl-C disabled
(ConsoleFlags set), couldn't turn it on as the process was detached
from unix console.
- now, SIGINT handling is moved to kernelbase (and can be turned on/off at
application will),
- when creating a new windows group id, the child will be detached from
unix console, so will no longer receives the SIGINT from ctrl-c in unix
console (if parent was attached to this unix console).
Signed-off-by: Eric Pouech <epouech@codeweavers.com>
The 'status' field of send_socket_request is always either
STATUS_PENDING or STATUS_DEVICE_NOT_READY, and the 'total' field is
always zero.
Replace the 'status' field with 'force_async' boolean field, and get rid
of the 'total' field entirely.
Also, clean up the send_socket handler code a bit.
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Make send_socket alert the async immediately if poll() call detects that
there are incoming data in the socket, bypassing the wineserver's main
polling loop.
For sock_transmit, we always mark the async as pending and set the IOSB
(unless async allocation has failed).
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The client can set mark_pending to indicate that the full-blown I/O
completion mechanism shall be triggered (asynchronous completion) even
if the status indicates failure.
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The 'status' field of recv_socket_request is always either
STATUS_PENDING or STATUS_DEVICE_NOT_READY, and the 'total' field is
always zero.
Replace the 'status' field with 'force_async' boolean field, and get rid
of the 'total' field entirely.
Also, clean up the recv_socket handler code a bit.
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Make recv_socket alert the async immediately if poll() call detects that
there are incoming data in the socket, bypassing the wineserver's main
polling loop.
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
If the server detects that an I/O request could be completed immediately
(e.g. the socket to read from already has incoming data), it can now
return STATUS_ALERTED to allow opportunistic synchronous I/O. The Unix
side will then attempt to perform I/O in nonblocking mode and report
back the I/O status to the server via the new server request
"set_async_direct_result". If the operation returns e.g. EAGAIN
or EWOULDBLOCK, the client can opt to either abandon the request (by
specifying an error status) or poll for it in the server as usual (by
waiting on the wait handle).
Without such mechanism in place, the client cannot safely perform
immediately satiable I/O operations synchronously, since it can
potentially conflict with other pending I/O operations that have already
been queued.
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Only really an optimization (plus it makes the code a little conceptually simpler).
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Based on a patch by Chip Davis.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=30155
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Although there is arguably an advantage to saving a server request, the impetus
for this patch is make it easier for the server to process the IRP return status
before (or at the same time as) it processes the IOSB status. This allows
simpler handling of the case where the IRP handler returns STATUS_PENDING but
completes the IRP before returning.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This fixes a regression introduced by 97afac469f.
If we make a request on an asynchronous device handle, and the IRP handler
returns STATUS_PENDING, wait_async() will return STATUS_PENDING, as intended.
However, if the async object is signaled before the user has a chance to call
wait_async() [e.g. if get_next_device_request is called quickly enough], select
will return STATUS_PENDING immediately, which causes server_select() to think
the object is not signaled, and wait for a select reply forever.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51277
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51295
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
