ClientSocket might have pending operations associated with it, so we should
not delete it until those operations fire.
This aligns ClientSocket::IsClosed with IsClosed implementation for other
handles, which check if handle has any associated pending operations.
The situation that sometimes arises it that if we issue Read, Disconnect operation,
they might complete in the opposite order DisconnectComplete, ReadComplete, which
is why we need to check for pending operations.
MSDN contains sentences like these: "Please note that while the packets are
queued in FIFO order they may be dequeued in a different order."
It seems that a more uniform fix would be to it increment a reference count
of a handle whenever an asynchronous operation is started and decrement it
whenever it is completed - but such fix requires much more thorough
refactoring of eventhandler_win.cc.
Bug: https://github.com/flutter/flutter/issues/22558
Change-Id: I4e6a7d5fdeaa85b9903d005b5bb95338033228f1
Reviewed-on: https://dart-review.googlesource.com/c/90484
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Jonas Termansen <sortie@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This is a reland of https://dart-review.googlesource.com/c/sdk/+/62484
with the following changes:
- _NativeSocket.connect now drops references to pending sockets on
an error or successful connection.
- eventhandlers are updated to ignore unset Dart ports on a close
command.
- Test updated to account for new SocketException.
This is the second part of https://dart-review.googlesource.com/c/sdk/+/62484
This CL adds a startConnect method to Socket types that returns
a ConnectionTask object that can be cancelled. Cancelling
a ConnectionTask closes any sockets that were opened for the
connection attempt that are not yet connected to the host.
This allows a closing HttpClient to close sockets for pending
requests whose sockets weren't fully connected yet.
related https://github.com/flutter/flutter/issues/18617
Change-Id: I47fe3564e41197d622079aad4bb644bbdfe0bfe8
Reviewed-on: https://dart-review.googlesource.com/63040
Reviewed-by: Zach Anderson <zra@google.com>
Commit-Queue: Zach Anderson <zra@google.com>
If an Isolate touches the 'stdio' getter, a _NativeSocket with
attached finalizer is created for it. Previously, when such an
Isolate exited, the finalizer would close the underlying
file descriptor. This CL changes the finalizer for stdin such
that the native objects will be cleaned up, but the underlying
file descriptor will not be closed. The underlying file
descriptor will now only be closed if the stdin stream
subscription is explicitly canceled.
Accessing the stdin getter after the stream is explicitly
canceled will result in a FileSystemException.
See also: https://github.com/dart-lang/test/issues/583fixes#29229R=rmacnak@google.com
Review-Url: https://codereview.chromium.org/2791423002 .
The finalizer sends the "close" message to the EventHandler for the
file descriptor in the _NativeSocket's native field. To avoid races and
spurious messages, this CL stores a pointer to a wrapper object in the
native field instead of the file descriptor. All messsages about the
_NativeSocket sent to the EventHandler use the wrapper object instead of
the file descriptor. When the EventHandler closes the file, the file
descriptor in the wrapper object is set to -1 so that the finalizer will
instead do nothing.
On Windows, there is another level of indirection since the OS HANDLEs
were already wrapped in various kinds of Handle objects. As an additional
complication, ClientSocket close on Windows is asynchronous, so the
EventHandler may shutdown before all of the ClientSocket Handles can be
destroyed.
related #27898, #28081R=johnmccutchan@google.com
Review-Url: https://codereview.chromium.org/2760293002 .
Like HOST_ARCH_*, HOST_OS_* describes the OS the VM is running on, which may be different from the OS the VM is generating code for during AOT compilation.
Currently we conflate the two when emitting AOT as assembly, and we get away with it because Flutter only uses assembly for targeting iOS and one can only target iOS from a Mac, but we expect to use assembly for Android as well so native tools can unwind Dart frames.
R=zra@google.com
Review-Url: https://codereview.chromium.org/2750843003 .
When cancelling a subscription to stdin, there may be pending I/O operation
that need to be explicitly cancelled before closing the stdin handle.
Otherwise the program would sit waiting for input (until CR is pressed).
Fixes dart-lang/pub#1502
Fixes#22940R=zra@google.com
Review-Url: https://codereview.chromium.org/2650063003 .
These threads are polluting the exit code despite using the better
ExitProcess call. Instead of adding back Thread::Join, I've instead
inlined the call into the eventhandler to make it easier to be sure
the open handles are closed.
R=johnmccutchan@google.com
Review URL: https://codereview.chromium.org/1989463003 .
Also:
- Reaps exited threads in the thread pool before putting
a thread on the idle list so that a new arriving task
isn't blocked on a supposedly idle thread in the middle
of a join.
- Stops trying to join eventhandler threads on
Windows. Now that we're using the correct exit() call,
we probably don't have to worry about exit code pollution,
so joining the threads is unnecessary.
related #26400R=asiva@google.com, iposva@google.com
Review URL: https://codereview.chromium.org/1978153002 .
Previously we would compile in implementaitions of native calls for
IO functions that would never be used. This CL provides implementations
that throw a Dart exception if they're called by mistake. It also uses
a DART_IO_DISABLED preprocessor define to clean up the build files and
check that we're not including code we shouldn't.
R=iposva@google.com, johnmccutchan@google.com
Review URL: https://codereview.chromium.org/1839463002 .
Ryan Macnak