Skip to content

Windows Port Continuation #1810

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.

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
merged 15 commits into from
Dec 21, 2018
Merged

Windows Port Continuation #1810

merged 15 commits into from
Dec 21, 2018

Conversation

compnerd
Copy link
Member

Peel off another 2 changes from the Windows port stack.

@compnerd
Copy link
Member Author

CC: @millenomi @phausler @parkera

@compnerd
Copy link
Member Author

@swift-ci please test

@@ -428,7 +428,7 @@ static __CFPortSet __CFPortSetAllocate(void) {
result->used = 0;
result->size = 4;
result->handles = (HANDLE *)CFAllocatorAllocate(kCFAllocatorSystemDefault, result->size * sizeof(HANDLE), 0);
CF_SPINLOCK_INIT_FOR_STRUCTS(result->lock);
CF_LOCK_INIT_FOR_STRUCTS(result->lock);
Copy link
Member Author

Choose a reason for hiding this comment

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

Note that result->lock is of type CFLock_t on L415.

@compnerd
Copy link
Member Author

@swift-ci please test

The previous error downgrade exposes the fact that the callback had a
new parameter added that we did not provide on Windows.  Provide a
placeholder for now.
Windows does not have the same semantics for the thread clean up when
using FLS (TLS does not support callbacks on destructor).  Simply wipe
out everything on attempt one.
Update the macro to `CF_LOCK_INIT_FOR_STRUCT`.  This repairs the windows
build.
The Windows TLS setup path is different from the POSIX path.  Do not
doubly define the TLS keys.
MessagePorts are a Mach feature and do not have an equivalent
implementation on Windows.  Remove the header inclusion.
@compnerd
Copy link
Member Author

@swift-ci please test

Since the latter is more generic, permitting setting the name of a given
thread rather than the current thread, re-implement
`_NS_pthread_set_name` in terms of `_CFSetThreadName`.
Windows does not have POSIX threads.  Provide an emulation stub for
`pthread_equals` that uses the underlying Win32 APIs to compare the
thread reference (HANDLE).
This is just a macro to use `GetCurrentThread` to get the current
thread's handle much like `pthread_self`.
Reconcile the `CF_EXPORT` and `CF_CROSSPLATFORM_EXPORT` macro
decorations.  Fix a style issue where a symbol was being marked with
`CF_EXPORT` in the definitions rather than the declaration which is not
the intended use of the `CF_EXPORT` macro.
The thread handles are no longer structures, but raw Windows threading
references (HANDLES).  Adjust the macros accordingly.
The windows startup path is slightly different from Linux.  Correct the
references to the TSD initialization and teardown.
The parameter type was declared in the declaration making the type
invisible to all other code as the type becomes anonymous.  Forward
declare the structure.
Pass the `-fcf-runtime-abi` flag via `/clang` to ensure that clang gets
the flag.  This also avoids CMake's annoying deduplication of flags
which prevent the use of `-Xclang`.
The dependencies should be shared, avoid the search and just pass long
the variables to the sub-configure.
On Windows, `CFLock_t` is already an unfair lock.  Simply add some
macros to use `CFLock_t` on Windows as it is not as lightweight on
Darwin.
@compnerd
Copy link
Member Author

@swift-ci please test

@compnerd
Copy link
Member Author

@parkera - is this okay to merge?

@compnerd compnerd merged commit a7f12d0 into swiftlang:master Dec 21, 2018
@compnerd compnerd deleted the windows-4 branch December 21, 2018 23:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants