`Handle` objects which used by Windows specific implementation of
`EventHandler` have complicated life cycle and haphazard approach
to locking. This CL is the first in a series of CLs which attempts
to clean this up a bit - with a final goal to avoid recursively
locking `Handle::monitor_`.
In this CL we remove `Handle::EnsureInitialized` method which
was primarily responsible for associating `HANDLE` with
`EventHandler`'s completion port. Instead we move this logic
into `Handle` constructor.
We also cleanup reference counting logic applied to handles which
participate in asynchronous operations: instead of eagerly
incrementing reference count when `HANDLE` is associated with
the completion port we increment it whenever asynchronous operation
is in progress and decrement it when it completes. This makes the
code much simpler to reason about and avoids necessity to write
code like:
handle->Release();
handle->Release();
accompanied with comments explaining why we need to drop
two references due to eager increment.
Finally we cleanup the handling of provider-specific extensions
accessed through `WSAIoctl`'s `SIO_GET_EXTENSION_FUNCTION_POINTER`.
We were fetching them for every individual socket instead of
fetching them once and caching them globally.
TEST=ci
Cq-Include-Trybots: luci.dart.try:vm-win-debug-x64-try,pkg-win-release-try,analyzer-win-release-try,vm-win-release-x64-try
Change-Id: Ia8b391b713b1a1afb9df9e931eada6abf97f7854
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/378140
Reviewed-by: Martin Kustermann <kustermann@google.com>
i.e. #ifndef VM_WHATEVER -> #ifndef RUNTIME_VM_WHATEVER
This lets us remove a hack from the PRESUBMIT.py script that existed
for reasons that are no longer valid, and sets us up to add some
presubmit checks for the GN build.
R=asiva@google.com, rmacnak@google.com
Review URL: https://codereview.chromium.org/2450713004 .
This CL includes fixes for the following issues:
a) The event handler created listening socket metadata (values of a hashtable
indexed by filedescriptor) sometimes as SocketData and sometimes as
ListeningSocketData depending whether the socket has been listened to or not.
This was very buggy, in particular because multiple isolates can have a
reference to the same server socket in different states (opened, listened,
closed).
=> This should be fixed by sending the file descriptior typeMask always to the
eventhandler.
b) A server socket cloned via the ServerSocketReference mechanism, opens a
receive port for sending (fd, address, port) to isolates/... which want to
create a server socket from the reference.
This receive port was not closed properly when calling only close() (and not
listening first).
=> This should be fixed by closing this receiveport on the ServerSocket.close()
call as well.
c) It was assumed in the event handler that a close command needs to have the
Dart_Port in a hash table. But this is only the case if the user actually
listened to the ServerSocket. Otherwise the event handler does not know about
the server socket. This caused a NULL dereference which resulted in a SEGFAULT.
=> This should be fixed by checking if the Dart_Port is in the hashmap of the
ListeningSocketData or not.
d) Too many bits were considered when extracting token count in C++ code.
The CL includes a regression test which should trigger these issues.
BUG=21384,21383
R=sgjesse@google.com
Review URL: https://codereview.chromium.org//665823007
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@41276 260f80e4-7a28-3924-810f-c04153c831b5
This the initial commit for adding a thread pool to the Dart
server. For now it is hidden behind a flag (--enable_thread_pool)
and when enabled just starts up and processes 100 void tasks.
Mac OS implementation is not tested and Windows implementation is
still pending.
As we are currently not sharing anything between bin/ and vm/ I
have just used pthread calls directly in the Linux and Mac OS
implementation code. However with Monitor and Thread classes from
vm/ the thread pool could be written platform independently. This
can always be changed later.
R=ager@google.com
BUG=
TEST=
Review URL: http://codereview.chromium.org//8983017
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@2946 260f80e4-7a28-3924-810f-c04153c831b5
When using stdout/stderr it is no longer necessary to explicitly
close the streams for the program to terminate. The automatic
close is handled by always closing the associated receive port
for write only streams when not waiting for any events. If a
close or error handler is installed for stdout/stderr these will
still keep the program alive.
For stdin better handling of the difference between sockets and
pipes have been immplemented. As a special case for stdin when
reading from a terminal the a POLLIN signal with 0 available
bytes is treated as end-of-file. This will trigger when pressing
ctrl-d in a terminal as POLLHUP is not set in that situation.
R=ager@google.com
BUG=
TEST=
Review URL: http://codereview.chromium.org//8533005
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@1507 260f80e4-7a28-3924-810f-c04153c831b5
Sockets now supports being half-closed for either reading or writing. When a socket is closed it is by default closed for both read and write and the underlying file descriptor is destroyed. However the socket close can be asked to only half-close the socket to send end of stream to the other end and still have the ability to receive more data.
The close event on a socket is only emitted when the socket is closed by the other end. Both half-close and full-close by the other end is reported as a close event. If a socket is already half closed the close event will automatically destroy the socket.
The streams on the sockets also takes advantage of this. A socket input stream will report a close event when the other end closed. A socket output stream will half-close the socket when close is called making it possible to still receive data on the input stream. When both streams have been closed the socket is destroyed.
For sockets operating on pipes they are initially created as half-closed for either reading or writing depending on which type of pipe a socket object is based on. A pipe for writing will start half-closed for reading so if it is only half-closed for writing the socket will still be destroyed. Same with a pipe for reading that will start half-closed for writing and when a close event is received half-closing the other direction will destroy the socket. Socket objects based on pipes are only exposed through streams.
Extended the socket close test to test a number of different scenarios.
Also refactor the socket data C++ object to encapsulate more socket information and operations.
Now the Linux and Mac OS versions are 100% the same as it turned out that using POLLRDHUP on Linux was not required any more.
R=ager@google.com
BUG=
TEST=
Review URL: http://codereview.chromium.org//8437090
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@1196 260f80e4-7a28-3924-810f-c04153c831b5
This moved some of the handling of the data on a socket to a socket data object.
This is a step in preparation for another change where more state will be stored on socket data object.
This is also a step in moving from an array of socket data objects indexed by the file descriptor to a hash map of socket data objects.
R=ager@google.com
BUG=
TEST=
Review URL: http://codereview.chromium.org//8431027
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@1001 260f80e4-7a28-3924-810f-c04153c831b5
Slava Egorov