[webkit-dev] Fwd: Port WebKit to GNUstep

[Daniel Ferreira (theiostream)]

On Thu, May 11, 2017 at 11:58 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> Are you intending to maintain this port going forward? The bar for
> introducing a new port in the WebKit repository is pretty high due to
> the maintenance cost it incurs to all other contributors. Unless
> you're intending to maintain your own port, and then contribute to the
> rest of the WebKit project unrelated to your port work, we kindly ask
> you to maintain your port in some downstream repository such as a
> GitHub fork.
> - R. Niwa

This is a very fair request – and thank you for specifying what "the
bar is higher" actually means. This was very unclear from the previous
response. 1) I do not intend to cause any liability to the project; 2)
Becoming a WebKit contributor is not a scenario I discard depending on
the outcome of this (since I naturally hope to learn about the
project's internal APIs and other needs over this effort), but anyway,
I don't believe this is the place to talk about personal involvement
matters.

That being said, I'd like to address a couple of issues that go beyond
GNUstep and that are actual issues for building the Mac port on
non-Darwin hosts, even if we hypothetically had Cocoa seamlessly
running on Linux (which is an issue that transcends GNUstep, with a
lot of good work being done on things like swift-corelibs-foundation).

The first issue is with MemoryPressureHandlerCocoa.mm. We compile that
automatically if we are building a Mac port, and we don't check for
OS(DARWIN) before relying on Mach API headers (which naturally breaks
everything). It seems like we should take that into account before
just compiling the file, and if we discover we are on OS(LINUX), we
should build the Linux pressure handlers instead. If that does in fact
work is another question, and most likely would require adjustments.

In my experiment, I built the Linux pressure handler instead of the
Mac one and had to do this tweak:

Index: wtf/linux/MemoryPressureHandlerLinux.cpp
===================================================================
--- wtf/linux/MemoryPressureHandlerLinux.cpp (revision 214620)
+++ wtf/linux/MemoryPressureHandlerLinux.cpp (working copy)
@@ -117,7 +117,7 @@
     }, this, nullptr);
     g_source_attach(m_source.get(), nullptr);
 #else
-    m_threadID = createThread("WTF: MemoryPressureHandler", [this] {
readAndNotify(); }
+    m_threadID = createThread("WTF: MemoryPressureHandler", [this] {
readAndNotify(); });

 #endif
 }
---

We have a missing ')' here. Apparently no one ever had a build
configuration that preprocessor-branched here.

The other issue was related to the main thread code. On
MainThread.cpp, we check for !OS(DARWIN) to define a isMainThread()
symbol. If we build the Mac port with a non-Darwin-OS configuration,
we get duplicated symbols from MainThreadMac.mm. This is another issue
with assuming Mac port means OS(DARWIN), and we should do due
adjustments to MainThreadMac.mm to handle this case (this time I'm not
quite sure how that would be done).

Another issue with MainThreadMac.mm is its assumption that
pthread_main_np() will be available (it is not on Linux). I managed to
get it working by applying this hack, borrowed from a Linux port of
libdispatch:

Index: wtf/mac/MainThreadMac.mm
===================================================================
--- wtf/mac/MainThreadMac.mm (revision 214620)
+++ wtf/mac/MainThreadMac.mm (working copy)
@@ -37,6 +37,17 @@
 #import <wtf/HashSet.h>
 #import <wtf/Threading.h>

+#if __linux__
+#include <unistd.h>
+#include <sys/syscall.h>
+#include <sys/types.h>
+
+static inline int pthread_main_np()
+{
+    return syscall(SYS_gettid) == getpid() ? 1 : 0;
+}
+#endif
+

 #if USE(WEB_THREAD)
 #include <wtf/ios/WebCoreThread.h>
 #endif
---

Again, this is another issue that needs to be solved with some more
elaborate checks for OS(DARWIN) and handling the non-Darwin cases.

I'd really appreciate comments on these issues, and thank you for the
quick responses.

-- Daniel.