Skip to content

Complete pending write operations before canceling io. #628

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
PaulHigin merged 3 commits into from
Apr 6, 2023
Merged

Complete pending write operations before canceling io. #628

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
31aad0c
Complete pending write operations before canceling io.
christophergreenettd Oct 27, 2022
c73e80b
Removed comment, question has been addressed in mr.
christophergreenettd Apr 5, 2023
5ed0a40
include useful comment from vthiebaut10
christophergreenettd Apr 5, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 14 additions & 2 deletions contrib/win32/win32compat/termio.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -260,6 +260,18 @@ int
syncio_close(struct w32_io* pio)
{
debug4("syncio_close - pio:%p", pio);

/* Flush descriptor.*/
Copy link
Collaborator

@vthiebaut10 vthiebaut10 Apr 4, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar justification as:

openssh-portable/contrib/win32/win32compat/fileio.c

Lines 1089 to 1100 in cdee736

/*
* we report to POSIX app that an async write has completed as soon its
* copied to internal buffer. The app may subsequently try to close the
* fd thinking everything is written. IF the Windows handle is closed
* now, the pipe/file io write operation may terminate prematurely.
* To compensate for the discrepency
* wait here until async write has completed.
* If you see any process waiting here indefinitely - its because no one
* is draining from other end of the pipe/file. This is an unfortunate
* consequence that should otherwise have very little impact on practical
* scenarios.
*/

Suggested change
/* Flush descriptor.*/
/*
* Wait for io write operation that is called by worker thread to terminate
* to avoid the write operation being terminated prematurely by CancelIoEx.
* If you see any process waiting here indefinitely - its because no one
* is draining from other end of the pipe. This is an unfortunate
* consequence that should otherwise have very little impact on practical
* scenarios.
*/

Feel free to modify this comment with any details that you think is relevant.

Copy link

@PaulHigin PaulHigin Apr 4, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment is similar to alternate path code for the file close operation, so I think it makes sense have it here as well, since we are using the same wait pattern.

Copy link
Author

@tessprime tessprime Apr 5, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this was basically to perform the same logic before and after. My understanding/recollection is the sleep is actually needed to ensure that the queue actually gets drained.

Copy link
Collaborator

@vthiebaut10 vthiebaut10 Apr 5, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm just wondering if the queue needs to be drained immediately after the write operation terminates, or if we can just have one SleepEx call once both the read and write operation have terminated. I don't think it hurts to have it there, so I am good to merge as is. But I'm just wondering if it's needed.

if (pio->write_details.pending) {
WaitForSingleObject(pio->write_overlapped.hEvent, INFINITE);

/* drain queued APCs */
SleepEx(0, TRUE);
Copy link
Collaborator

@vthiebaut10 vthiebaut10 Apr 4, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason why you added this call to SleepEx to this if statement block?

}

// This call is likely racy, there's no guarantee
// that a thread has begun IO operations when it's called.
// Why stop io operations when we're going to close it anyhow?
CancelIoEx(WINHANDLE(pio), NULL);
Copy link
Author

@tessprime tessprime Oct 27, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, this comment is mostly here because I'm unsure about what CancelIoEx is supposed to be doing here. If it is needed, I think its not doing what its supposed to be doing because of the possible race condition. If it is not needed, then I believe that this PR can be simplified to just removing it.

Copy link
Collaborator

@vthiebaut10 vthiebaut10 Apr 4, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We will take the change as it is. You can delete this comment.


/* If io is pending, let worker threads exit. */
Expand All @@ -276,10 +288,10 @@ syncio_close(struct w32_io* pio)

WaitForSingleObject(pio->read_overlapped.hEvent, INFINITE);
}
if (pio->write_details.pending)
WaitForSingleObject(pio->write_overlapped.hEvent, INFINITE);

/* drain queued APCs */
SleepEx(0, TRUE);

/* TODO - fix this, closing Console handles is interfering with TTY/PTY rendering */
if (FILETYPE(pio) != FILE_TYPE_CHAR)
CloseHandle(WINHANDLE(pio));
Expand Down