過去に書いた文章を読み直すと、自分の変化と世界の変化が響き合うとともに軋み合い、交錯に眩暈を覚える。たとえば4年前にAJAXやFlashを題材にして書いた記事では、Webページがアプリになる可能性を考察していた。その可能性の一端は現在HTML5として実現している。ただし、HTML5には技術的に新しいことは何もなく、政治的理由により遅れてやってきた標準化にすぎない。また、同じく2006年に、今回と同じく過去を回顧している文章では、「無駄な部分を省いたコミュニケーションの需要は残るはずであり、むしろ参入障壁が十分に低ければシンプルなものがリッチなものを出し抜く可能性が十分にある」と書いており、こちらはTwitterとして顕在化してきた。しかし2006年の時点では、巨大なデータを合成してシンプルなインターフェイスに落とし込む処理を、自分では全くイメージできなかった。

8bit時代のビデオゲームは、表現能力を欠いたことにより洋の東西を問わない普遍性を獲得した。21世紀的なシンプルさの形式が普遍性を備えるには、世界中のユーザーの要求に即座に応答できるシステムを背後に組織化しなければならない。スマートフォン、クラウド… ハードウェアにいくつセンサーやプロセッサーが導入されようが、ソフトウェアデザインは本質的に自由だ。その広すぎる可能性の中から、有限の資源に応じた、核心を衝く着想が常に求められている。

この2年間は、専らWebブラウザーの発展に注目してきた。Jargon Fileにも載っている用語でwheel of reincarnation(輪廻)というものがある。ある処理に特化したプロセッサ(たとえばGPU)をCPUから分離した場合に、後年そのプロセッサの汎用計算性能が強化されるにつれ結局はCPU上でソフトウェア実装した方が効率的になり、再度CPUに吸収される…というサイクルが反復されることを指して輪廻と呼ぶ。Webブラウザーも、PCの本質的な機能であるということになれば、OSに統合されるのが望ましい。ところが、政治的事情からWindowsではそうはなっていない。iOSやAndroid、Chrome OSでは統合されているというのにWindowsではそうはなっていないというのは笑うしかない。どちらが望ましいのだろうか。一つだけ明らかなのは、私は自由なソフトウェアを支持するということである。つまり、iOSの現状が、競争を排除するようなものであるとすれば、私はそれを忌避するし、Apple社の製品は購入しない。私にとってのiPhoneとは、Androidの健全な発展を促す触媒でしかない。

Webブラウザーに関して、直近の動きで一番注目しているのはChromelessだ。XULがHTMLに溶け出している。自分が欲しかったコンセプトがそのままプロジェクトになっていて、嬉しかった。他に興味深かったのは、Beyond3Dで教えてもらった、EAによるPS3/Xbox360へのWebKit移植のベースに利用されていたOrigyn Web Browser。現在サイトが落ちているようなのでEA側のコードしか見ることは出来ない。EA側コードは、Paul Pedriana氏によるEASTL実装を含む(ドキュメントにはBoost.Intrusiveみたいなコンテナーが入っていると書かれているが見つからなかった)。

次に向けて、学ばなければならないことは山ほどある。

First let me recap what WebKit2 actually is and how it’s related to the current WebKit with the official high level design document as the reference.

For those who are not very familiar with WebKit, it may be confusing that WebKit as a whole contains a part that shares the same WebKit name. WebKit as the framework has 3 major components – WebKit, WebCore, and JavaScriptCore – as you see in the source directory. WebCore is the layout engine that parses an HTML5 web page into a DOM tree and renders a render tree created out of a DOM tree with CSS information computed on each node. In addition to the abstract or platform-agnostic parts, it contains platform-specific implementations such as graphics and I/O if necessary. JavaScriptCore is the JavaScript engine. Google Chrome swaps it with its own V8 engine whereas Safari uses JavaScriptCore under the name Nitro. JavaScriptCore/V8 bindings to DOM live in the bindings directory in the WebCore. A WebKit user controls WebCore through a high-level API set which is differently implemented for each platform. The WebKit directory contains such an API set. For example, the Windows version of Safari implements it by COM classes in C++ in the win directory while the Mac version does it with Objective-C in the mac directory. Due to some dependency on proprietary libraries owned by Apple found in the Windows implementation for Safari, WebKit embedders should try other API layer implementations such as Gtk+ or Qt unless adopting Chromium suits the need.

WebKit2 effectively splits this WebKit API layer into two. The first part, UI Process, is obviously the interface accessed by the platform API user. Inside this shell, or outside if you follow its process model, there are Web Processes that implement the second layer of the new WebKit2 API. The UI Process controls multiple Web Processes through accessing the API based on an IPC protocol agreed by them. The API of the UI Process should work in almost the same way for a user as the old API except that the WebKit2 API are non-blocking. Most likely the underlying WebCore doesn’t change much as a multiprocess architecture has typically a lot less synchronization issues than a multithreaded architecture. Also the current WebKit API should continue to work alongside of the WebKit2 development unless Chromium tries to merge it, but the prospect looks unlikely at this point.

Let’s take a look at the source code itself. The most easiest entry point would be an example that uses WebKit2 API. Fortunately it’s already available as the MiniBrowser. Right now there are 3 implementations: Mac, Windows, and Qt. The Mac version seems the most active, the next is the Qt version. The Windows version is a plain Windows application that is not related to the current Windows version of Safari for some reason. Since it’s the most simple, I start from there. The main.cpp has its message loop.

int WINAPI _tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpstrCmdLine, int nCmdShow)
{
    MiniBrowser::shared().initialize(hInstance);

    // Create and show our initial window.
    MiniBrowser::shared().createNewWindow();

    MSG message;
    while (BOOL result = ::GetMessage(&message, 0, 0, 0)) {
        if (result == -1)
            break;
        ::TranslateMessage(&message);

        if (!MiniBrowser::shared().handleMessage(&message))
            ::DispatchMessage(&message);
    }

    return 0;
}

MiniBrowser::shared() returns the static singleton of the MiniBrowser object. So it calls MiniBrowser::createNewWindow() which then creates a BrowserWindow object with its member BrowserView object (m_browserView). The actual browser view is created at the end of BrowserWindow::onCreate. It calls BrowserView::create.

void BrowserView::create(RECT webViewRect, BrowserWindow* parentWindow)
{
    assert(!m_webView);

    bool isShiftKeyDown = ::GetKeyState(VK_SHIFT) & HIGH_BIT_MASK_SHORT;

    WKContextRef context;
    if (isShiftKeyDown)
        context = WKContextGetSharedThreadContext();
    else
        context = WKContextGetSharedProcessContext();

    WKPageNamespaceRef pageNamespace = WKPageNamespaceCreate(context);

    m_webView = WKViewCreate(webViewRect, pageNamespace, parentWindow->window());

    WKPageUIClient uiClient = {
        0,              /* version */
        parentWindow,   /* clientInfo */
        createNewPage,
        showPage,
        closePage,
        runJavaScriptAlert,
        runJavaScriptConfirm,
        runJavaScriptPrompt,
        setStatusText,
        mouseDidMoveOverElement,
        0               /* didNotHandleKeyEvent */
    };

    WKPageSetPageUIClient(WKViewGetPage(m_webView), &uiClient);
}

A lot of things seem to happen, but apparently this is the starting point of embedding WebKit2. isShiftKeyDown is probably there for the debug purpose, it’s used to switch the context. WKContextGetSharedThreadContext is declared in WKContextPrivate.h while WKContextGetSharedProcessContext is declared in WKContext.h, both are WebKit2 C API functions. These actually refer to the WebContext object of the UI Process.

WebContext* WebContext::sharedProcessContext()
{
    WTF::initializeMainThread();
    RunLoop::initializeMainRunLoop();
    static WebContext* context = adoptRef(new WebContext(ProcessModelSharedSecondaryProcess, String())).leakRef();
    return context;
}

WebContext* WebContext::sharedThreadContext()
{
    RunLoop::initializeMainRunLoop();
    static WebContext* context = adoptRef(new WebContext(ProcessModelSharedSecondaryThread, String())).leakRef();
    return context;
}

This RunLoop is declared in RunLoop.h,but most of its work is defined in the platform-specific implementation, for example the Windows version can be found in RunLoopWin.cpp. It’s a message queue window for WebKit work items. So, back to the BrowserView::create, it creates a WebContext of some flavor. Its member declaration is like this.

class WebContext : public APIObject {
public:
    static const Type APIType = TypeContext;

    static WebContext* sharedProcessContext();
    static WebContext* sharedThreadContext();

    static PassRefPtr<WebContext> create(const String& injectedBundlePath);

    ~WebContext();

// snip

private:
    WebContext(ProcessModel, const String& injectedBundlePath);

    virtual Type type() const { return APIType; }

    void ensureWebProcess();
    bool hasValidProcess() const { return m_process && m_process->isValid(); }
    void platformInitializeWebProcess(WebProcessCreationParameters&);

    static void languageChanged(void* context);
    void languageChanged();

    ProcessModel m_processModel;

    // FIXME: In the future, this should be one or more WebProcessProxies.
    RefPtr<WebProcessProxy> m_process;

    HashSet<WebPageNamespace*> m_pageNamespaces;
    RefPtr<WebPreferences> m_preferences;

    String m_injectedBundlePath;
    WebContextInjectedBundleClient m_injectedBundleClient;

    WebHistoryClient m_historyClient;

    PluginInfoStore m_pluginInfoStore;
    VisitedLinkProvider m_visitedLinkProvider;

    HashSet<String> m_schemesToRegisterAsEmptyDocument;
    HashSet<String> m_schemesToRegisterAsSecure;
    HashSet<String> m_schemesToSetDomainRelaxationForbiddenFor;

    Vector<pair<String, RefPtr<APIObject> > > m_pendingMessagesToPostToInjectedBundle;

    CacheModel m_cacheModel;

#if PLATFORM(WIN)
    bool m_shouldPaintNativeControls;
#endif
};

It has document-related objects such as WebHistoryClient and VisitedLinkProvider, also it has WebPreferences that should be applied to all pages. So WebContext is the class that represents a single web browser.

The other important member object is WebProcessProxy that is a proxy to a renderer process. As the comment suggests, it will be the proxy to multiple Web Processes in the future. The web process proxy is initialized before creating a web page by WebContext::ensureWebProcess.

void WebContext::ensureWebProcess()
{
    if (m_process)
        return;

    m_process = WebProcessManager::shared().getWebProcess(this);

    WebProcessCreationParameters parameters;

    parameters.applicationCacheDirectory = applicationCacheDirectory();

    if (!injectedBundlePath().isEmpty()) {
        parameters.injectedBundlePath = injectedBundlePath();

#if ENABLE(WEB_PROCESS_SANDBOX)
        char* sandboxBundleTokenUTF8 = 0;
        CString injectedBundlePathUTF8 = injectedBundlePath().utf8();
        sandbox_issue_extension(injectedBundlePathUTF8.data(), &sandboxBundleTokenUTF8);
        String sandboxBundleToken = String::fromUTF8(sandboxBundleTokenUTF8);
        if (sandboxBundleTokenUTF8)
            free(sandboxBundleTokenUTF8);

        parameters.injectedBundlePathToken = sandboxBundleToken;
#endif
    }

    parameters.shouldTrackVisitedLinks = m_historyClient.shouldTrackVisitedLinks();
    parameters.cacheModel = m_cacheModel;
    parameters.languageCode = defaultLanguage();
    parameters.applicationCacheDirectory = applicationCacheDirectory();

    copyToVector(m_schemesToRegisterAsEmptyDocument, parameters.urlSchemesRegistererdAsEmptyDocument);
    copyToVector(m_schemesToRegisterAsSecure, parameters.urlSchemesRegisteredAsSecure);
    copyToVector(m_schemesToSetDomainRelaxationForbiddenFor, parameters.urlSchemesForWhichDomainRelaxationIsForbidden);

    // Add any platform specific parameters
    platformInitializeWebProcess(parameters);

    m_process->send(Messages::WebProcess::InitializeWebProcess(parameters), 0);
}

WebProcessManager does simple creation of a Web Process proxy via WebProcessProxy::create dependent on the process model: Shared Secondary Process, Shared Secondary Thread, Secondary Process. The names are a bit confusing but Shared Secondary Thread means using threads for Web Processes, and Shared Secondary Process means using multiple processes. The last one manages multiple WebContext objects and correspondent Web Proxy objects in a hash map.

WebProcessProxy* WebProcessManager::getWebProcess(WebContext* context)
{
    switch (context->processModel()) {
        case ProcessModelSharedSecondaryProcess: {
            if (!m_sharedProcess)
                m_sharedProcess = WebProcessProxy::create(context);
            return m_sharedProcess.get();
        }
        case ProcessModelSharedSecondaryThread: {
            if (!m_sharedThread)
                m_sharedThread = WebProcessProxy::create(context);
            return m_sharedThread.get();
        }
        case ProcessModelSecondaryProcess: {
            std::pair<ProcessMap::iterator, bool> result = m_processMap.add(context, 0);
            if (result.second) {
                ASSERT(!result.first->second);
                result.first->second = WebProcessProxy::create(context);
            }

            ASSERT(result.first->second);
            return result.first->second.get();
        }
    }

    ASSERT_NOT_REACHED();
    return 0;
}

WebProcessProxy::create is just a call to WebProcessProxy::connect via its constructor.

PassRefPtr<WebProcessProxy> WebProcessProxy::create(WebContext* context)
{
    return adoptRef(new WebProcessProxy(context));
}

WebProcessProxy::WebProcessProxy(WebContext* context)
    : m_responsivenessTimer(this)
    , m_context(context)
{
    connect();
}

WebProcessProxy::~WebProcessProxy()
{
    ASSERT(!m_connection);

    for (size_t i = 0; i < m_pendingMessages.size(); ++i)
        m_pendingMessages[i].releaseArguments();

    if (m_processLauncher) {
        m_processLauncher->invalidate();
        m_processLauncher = 0;
    }

    if (m_threadLauncher) {
        m_threadLauncher->invalidate();
        m_threadLauncher = 0;
    }
}

void WebProcessProxy::connect()
{
    if (m_context->processModel() == ProcessModelSharedSecondaryThread) {
        ASSERT(!m_threadLauncher);
        m_threadLauncher = ThreadLauncher::create(this);
    } else {
        ASSERT(!m_processLauncher);

        ProcessLauncher::LaunchOptions launchOptions;
        launchOptions.processType = ProcessLauncher::WebProcess;
#if PLATFORM(MAC)
        // We want the web process to match the architecture of the UI process.
        launchOptions.architecture = ProcessLauncher::LaunchOptions::MatchCurrentArchitecture;
#endif
        m_processLauncher = ProcessLauncher::create(this, launchOptions);
    }
}

If the process model is Shared Secondary Thread, it creates a ThreadLauncher instance by its create method.

class ThreadLauncher : public ThreadSafeShared<ThreadLauncher> {
public:
    class Client {
    public:
        virtual ~Client() { }
        virtual void didFinishLaunching(ThreadLauncher*, CoreIPC::Connection::Identifier) = 0;
    };

    static PassRefPtr<ThreadLauncher> create(Client* client)
    {
        return adoptRef(new ThreadLauncher(client));
    }

Again, it’s just a proxy to ThreadLauncher::launchThread.

ThreadLauncher::ThreadLauncher(Client* client)
    : m_client(client)
{
    launchThread();
}

void ThreadLauncher::launchThread()
{
    m_isLaunching = true;

    CoreIPC::Connection::Identifier connectionIdentifier = createWebThread();

    // We've finished launching the thread, message back to the main run loop.
    RunLoop::main()->scheduleWork(WorkItem::create(this, &ThreadLauncher::didFinishLaunchingThread, connectionIdentifier));
}

ThreadLauncher::createWebThread is a platform-specific method. It’s defined in ThreadLauncherWin.cpp for Windows.

CoreIPC::Connection::Identifier ThreadLauncher::createWebThread()
{
    // First, create the server and client identifiers.
    HANDLE serverIdentifier, clientIdentifier;
    if (!CoreIPC::Connection::createServerAndClientIdentifiers(serverIdentifier, clientIdentifier)) {
        // FIXME: What should we do here?
        ASSERT_NOT_REACHED();
    }

    if (!createThread(webThreadBody, reinterpret_cast<void*>(clientIdentifier), "WebKit2: WebThread")) {
        ::CloseHandle(serverIdentifier);
        ::CloseHandle(clientIdentifier);
        return 0;
    }

    return serverIdentifier;
}

createThread is a utility function declared in the WTF namespace of JavaScriptCore. In wtf/Threading.cpp, it calls platform-specific createThreadInternal.

ThreadIdentifier createThread(ThreadFunction entryPoint, void* data, const char* name)
{
    // Visual Studio has a 31-character limit on thread names. Longer names will
    // be truncated silently, but we'd like callers to know about the limit.
#if !LOG_DISABLED
    if (strlen(name) > 31)
        LOG_ERROR("Thread name \"%s\" is longer than 31 characters and will be truncated by Visual Studio", name);
#endif

    NewThreadContext* context = new NewThreadContext(entryPoint, data, name);

    // Prevent the thread body from executing until we've established the thread identifier.
    MutexLocker locker(context->creationMutex);

    return createThreadInternal(threadEntryPoint, context, name);
}

For example, the Windows version is defined in wtf/ThreadingWin.cpp (for some reason this is not in a separate folder).

ThreadIdentifier createThreadInternal(ThreadFunction entryPoint, void* data, const char* threadName)
{
    unsigned threadIdentifier = 0;
    ThreadIdentifier threadID = 0;
    ThreadFunctionInvocation* invocation = new ThreadFunctionInvocation(entryPoint, data);
#if OS(WINCE)
    // This is safe on WINCE, since CRT is in the core and innately multithreaded.
    // On desktop Windows, need to use _beginthreadex (not available on WinCE) if using any CRT functions
    HANDLE threadHandle = CreateThread(0, 0, (LPTHREAD_START_ROUTINE)wtfThreadEntryPoint, invocation, 0, (LPDWORD)&threadIdentifier);
#else
    HANDLE threadHandle = reinterpret_cast<HANDLE>(_beginthreadex(0, 0, wtfThreadEntryPoint, invocation, 0, &threadIdentifier));
#endif
    if (!threadHandle) {
#if OS(WINCE)
        LOG_ERROR("Failed to create thread at entry point %p with data %p: %ld", entryPoint, data, ::GetLastError());
#elif defined(NO_ERRNO)
        LOG_ERROR("Failed to create thread at entry point %p with data %p.", entryPoint, data);
#else
        LOG_ERROR("Failed to create thread at entry point %p with data %p: %ld", entryPoint, data, errno);
#endif
        return 0;
    }

    threadID = static_cast<ThreadIdentifier>(threadIdentifier);
    storeThreadHandleByIdentifier(threadIdentifier, threadHandle);

    return threadID;
}

_beginthreadex is the underlying thread creation function on Windows. In this model, the thread ID is used as the return value which becomes CoreIPC::Connection::Identifier.

You may remember the single process model in Chromium as a mode akin to this Shared Secondary Thread prcess model in WebKit2.

OK let’s get back to the more interesting one, the Shared Secondary Process model that sports ProcessLauncher. When created via the create method, its constructor adds a function call to ProcessLauncher::launchProcess to the end of its WorkQueue singleton.

class ProcessLauncher : public ThreadSafeShared<ProcessLauncher> {
public:
    class Client {
    public:
        virtual ~Client() { }

        virtual void didFinishLaunching(ProcessLauncher*, CoreIPC::Connection::Identifier) = 0;
    };
// snip

    static PassRefPtr<ProcessLauncher> create(Client* client, const LaunchOptions& launchOptions)
    {
        return adoptRef(new ProcessLauncher(client, launchOptions));
    }

static WorkQueue& processLauncherWorkQueue()
{
    DEFINE_STATIC_LOCAL(WorkQueue, processLauncherWorkQueue, ("com.apple.WebKit.ProcessLauncher"));
    return processLauncherWorkQueue;
}

ProcessLauncher::ProcessLauncher(Client* client, const LaunchOptions& launchOptions)
    : m_client(client)
    , m_launchOptions(launchOptions)
    , m_processIdentifier(0)
{
    // Launch the process.
    m_isLaunching = true;
    processLauncherWorkQueue().scheduleWork(WorkItem::create(this, &ProcessLauncher::launchProcess));
}

WorkQueue::scheduleWork is defined as a platform-specific function. In the case of Windows, it’s based on the QueueUserWorkItem API that uses the thread pool of Windows OS. Again, ProcessLauncher::launchProcess is implemented in the platform-specific form. For Windows, it’s in win/ProcessLauncherWin.cpp.

void ProcessLauncher::launchProcess()
{
    // First, create the server and client identifiers.
    HANDLE serverIdentifier, clientIdentifier;
    if (!CoreIPC::Connection::createServerAndClientIdentifiers(serverIdentifier, clientIdentifier)) {
        // FIXME: What should we do here?
        ASSERT_NOT_REACHED();
    }

    // Ensure that the child process inherits the client identifier.
    ::SetHandleInformation(clientIdentifier, HANDLE_FLAG_INHERIT, HANDLE_FLAG_INHERIT);

    // To get the full file path to WebKit2WebProcess.exe, we fild the location of WebKit.dll,
    // remove the last path component, and then append WebKit2WebProcess(_debug).exe.
    HMODULE webKitModule = ::GetModuleHandleW(webKitDLLName);
    ASSERT(webKitModule);
    if (!webKitModule)
        return;

    WCHAR pathStr[MAX_PATH];
    if (!::GetModuleFileNameW(webKitModule, pathStr, WTF_ARRAY_LENGTH(pathStr)))
        return;

    ::PathRemoveFileSpecW(pathStr);
    if (!::PathAppendW(pathStr, webProcessName))
        return;

    String commandLine(pathStr);

    // FIXME: It would be nice if we could just create a CommandLine object and output a command line vector from it.
    Vector<UChar> commandLineVector;
    append(commandLineVector, commandLine);
    append(commandLineVector, " -type webprocess");
    append(commandLineVector, " -clientIdentifier ");
    append(commandLineVector, String::number(reinterpret_cast<uintptr_t>(clientIdentifier)));
    commandLineVector.append('\0');

    STARTUPINFO startupInfo = { 0 };
    startupInfo.cb = sizeof(startupInfo);
    PROCESS_INFORMATION processInformation = { 0 };
    BOOL result = ::CreateProcessW(0, commandLineVector.data(), 0, 0, true, 0, 0, 0, &startupInfo, &processInformation);

    // We can now close the client identifier handle.
    ::CloseHandle(clientIdentifier);

    if (!result) {
        // FIXME: What should we do here?
        DWORD error = ::GetLastError();
        ASSERT_NOT_REACHED();
    }

    // Don't leak the thread handle.
    ::CloseHandle(processInformation.hThread);

    // We've finished launching the process, message back to the run loop.
    RunLoop::main()->scheduleWork(WorkItem::create(this, &ProcessLauncher::didFinishLaunchingProcess, processInformation.hProcess, serverIdentifier));
}

CoreIPC::Connection::createServerAndClientIdentifiers creates a platform primitive for IPC (InterProcess Communication) between the UI Process and Web Processes. The whole implementation of IPC for WebKit2 is found in the CoreIPC directory. The Windows version of Connection::createServerAndClientIdentifiers uses Named Pipe for its IPC channel.

bool Connection::createServerAndClientIdentifiers(HANDLE& serverIdentifier, HANDLE& clientIdentifier)
{
    String pipeName;

    while (true) {
        unsigned uniqueID = randomNumber() * std::numeric_limits<unsigned>::max();
        pipeName = String::format("\\\\.\\pipe\\com.apple.WebKit.%x", uniqueID);

        serverIdentifier = ::CreateNamedPipe(pipeName.charactersWithNullTermination(),
                                             PIPE_ACCESS_DUPLEX | FILE_FLAG_FIRST_PIPE_INSTANCE | FILE_FLAG_OVERLAPPED,
                                             PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE, 1, inlineMessageMaxSize, inlineMessageMaxSize,
                                             0, 0);
        if (!serverIdentifier && ::GetLastError() == ERROR_PIPE_BUSY) {
            // There was already a pipe with this name, try again.
            continue;
        }

        break;
    }

    if (!serverIdentifier)
        return false;

    clientIdentifier = ::CreateFileW(pipeName.charactersWithNullTermination(), GENERIC_READ | GENERIC_WRITE, 0, 0, OPEN_EXISTING, FILE_FLAG_OVERLAPPED, 0);
    if (!clientIdentifier) {
        ::CloseHandle(serverIdentifier);
        return false;
    }

    DWORD mode = PIPE_READMODE_MESSAGE;
    if (!::SetNamedPipeHandleState(clientIdentifier, &mode, 0, 0)) {
        ::CloseHandle(serverIdentifier);
        ::CloseHandle(clientIdentifier);
        return false;
    }

    return true;
}

In Chromium, a similar operation is handled by its IPC Channel implementation. It may be interesting to compare it with the one in WebKit2.

bool Channel::ChannelImpl::CreatePipe(const std::string& channel_id,
                                      Mode mode) {
  DCHECK(pipe_ == INVALID_HANDLE_VALUE);
  const std::wstring pipe_name = PipeName(channel_id);
  if (mode == MODE_SERVER) {
    SECURITY_ATTRIBUTES security_attributes = {0};
    security_attributes.bInheritHandle = FALSE;
    security_attributes.nLength = sizeof(SECURITY_ATTRIBUTES);
    if (!GetLogonSessionOnlyDACL(
        reinterpret_cast<SECURITY_DESCRIPTOR**>(
            &security_attributes.lpSecurityDescriptor))) {
      NOTREACHED();
    }

    pipe_ = CreateNamedPipeW(pipe_name.c_str(),
                             PIPE_ACCESS_DUPLEX | FILE_FLAG_OVERLAPPED |
                                FILE_FLAG_FIRST_PIPE_INSTANCE,
                             PIPE_TYPE_BYTE | PIPE_READMODE_BYTE,
                             1,         // number of pipe instances
                             // output buffer size (XXX tune)
                             Channel::kReadBufferSize,
                             // input buffer size (XXX tune)
                             Channel::kReadBufferSize,
                             5000,      // timeout in milliseconds (XXX tune)
                             &security_attributes);
    LocalFree(security_attributes.lpSecurityDescriptor);
  } else {
    pipe_ = CreateFileW(pipe_name.c_str(),
                        GENERIC_READ | GENERIC_WRITE,
                        0,
                        NULL,
                        OPEN_EXISTING,
                        SECURITY_SQOS_PRESENT | SECURITY_IDENTIFICATION |
                            FILE_FLAG_OVERLAPPED,
                        NULL);
  }
  if (pipe_ == INVALID_HANDLE_VALUE) {
    // If this process is being closed, the pipe may be gone already.
    LOG(WARNING) << "failed to create pipe: " << GetLastError();
    return false;
  }

  // Create the Hello message to be sent when Connect is called
  scoped_ptr<Message> m(new Message(MSG_ROUTING_NONE,
                                    HELLO_MESSAGE_TYPE,
                                    IPC::Message::PRIORITY_NORMAL));
  if (!m->WriteInt(GetCurrentProcessId())) {
    CloseHandle(pipe_);
    pipe_ = INVALID_HANDLE_VALUE;
    return false;
  }

  output_queue_.push(m.release());
  return true;
}

Going back to ProcessLauncher::launchProcess, it locates the executable module for the Web Process and creates a new process with the given parameters. When it’s done, the callback function ProcessLauncher::didFinishLaunchingProcess is put on the work queue of the RunLoop. It then calls WebProcessProxy::didFinishLaunching since m_client is actually WebProcessProxy as you may notice if you remember what was going on in WebProcessProxy::connect. WebProcessProxy inherits ProcessLauncher::Client.

void ProcessLauncher::didFinishLaunchingProcess(PlatformProcessIdentifier processIdentifier, CoreIPC::Connection::Identifier identifier)
{
    m_processIdentifier = processIdentifier;
    m_isLaunching = false;

    if (!m_client) {
        // FIXME: Dispose of the connection identifier.
        return;
    }

    m_client->didFinishLaunching(this, identifier);
}

It then opens an IPC server connection (RefPtr<CoreIPC::Connection> m_connection) in WebProcessProxy::didFinishLaunching.

void WebProcessProxy::didFinishLaunching(ProcessLauncher*, CoreIPC::Connection::Identifier connectionIdentifier)
{
    didFinishLaunching(connectionIdentifier);
}

void WebProcessProxy::didFinishLaunching(ThreadLauncher*, CoreIPC::Connection::Identifier connectionIdentifier)
{
    didFinishLaunching(connectionIdentifier);
}

void WebProcessProxy::didFinishLaunching(CoreIPC::Connection::Identifier connectionIdentifier)
{
    ASSERT(!m_connection);

    m_connection = CoreIPC::Connection::createServerConnection(connectionIdentifier, this, RunLoop::main());
    m_connection->open();

    for (size_t i = 0; i < m_pendingMessages.size(); ++i) {
        CoreIPC::Connection::OutgoingMessage& outgoingMessage = m_pendingMessages[i];
        m_connection->sendMessage(outgoingMessage.messageID(), adoptPtr(outgoingMessage.arguments()));
    }

    m_pendingMessages.clear();

    // Tell the context that we finished launching.
    m_context->processDidFinishLaunching(this);
}

The IPC server in the UI Process hosts Web Processes. Connection::open is also implemented for a specific platform. Its Windows version starts listening for read and write state events on event handles to communicate with Web Processes. It’s a very standard server behavior.

bool Connection::open()
{
    // Start listening for read and write state events.
    m_connectionQueue.registerHandle(m_readState.hEvent, WorkItem::create(this, &Connection::readEventHandler));
    m_connectionQueue.registerHandle(m_writeState.hEvent, WorkItem::create(this, &Connection::writeEventHandler));

    // Schedule a read.
    m_connectionQueue.scheduleWork(WorkItem::create(this, &Connection::readEventHandler));

    return true;
}

Finally, WebContext::processDidFinishLaunching is called to do some preparation for its internal history and pending IPC messages.

void WebContext::processDidFinishLaunching(WebProcessProxy* process)
{
    // FIXME: Once we support multiple processes per context, this assertion won't hold.
    ASSERT(process == m_process);

    m_visitedLinkProvider.populateVisitedLinksIfNeeded();

    for (size_t i = 0; i != m_pendingMessagesToPostToInjectedBundle.size(); ++i) {
        pair<String, RefPtr<APIObject> >& message = m_pendingMessagesToPostToInjectedBundle[i];
        m_process->send(InjectedBundleMessage::PostMessage, 0, CoreIPC::In(message.first, WebContextUserMessageEncoder(message.second.get())));
    }
    m_pendingMessagesToPostToInjectedBundle.clear();
}

The above call stack is what happens when a new WebContext is initialized in BrowserView::create. The next thing it does is to call the WKPageNamespaceCreate API.

WKPageNamespaceRef WKPageNamespaceCreate(WKContextRef ownerContextRef)
{
    return toAPI(toImpl(ownerContextRef)->createPageNamespace());
}

It calls WebContext::createPageNamespace then WebPageNamespace::create.

class WebPageNamespace : public APIObject {
public:
    static const Type APIType = TypePageNamespace;

    static PassRefPtr<WebPageNamespace> create(WebContext* context)
    {
        return adoptRef(new WebPageNamespace(context));
    }

For now it seems WebPageNamespace does nothing when created except for some reference counting.

#ifndef NDEBUG
static WTF::RefCountedLeakCounter webPageNamespaceCounter("WebPageNamespace");
#endif

WebPageNamespace::WebPageNamespace(WebContext* context)
    : m_context(context)
{
#ifndef NDEBUG
    webPageNamespaceCounter.increment();
#endif
}

After creating a namespace for scripting, BrowserView::create calls the WKViewCreate API. For Windows, it’s just a call to WebView::create which instanciates WebView via its constructor.

WKViewRef WKViewCreate(RECT rect, WKPageNamespaceRef pageNamespaceRef, HWND parentWindow)
{
    RefPtr<WebView> view = WebView::create(rect, toImpl(pageNamespaceRef), parentWindow);
    return toAPI(view.release().releaseRef());
}

class WebView : public APIObject, public PageClient, WebCore::WindowMessageListener {
public:
    static PassRefPtr<WebView> create(RECT rect, WebPageNamespace* pageNamespace, HWND parentWindow)
    {
        return adoptRef(new WebView(rect, pageNamespace, parentWindow));
    }
    ~WebView();

// snip

virtual HWND nativeWindow();

    // WebCore::WindowMessageListener
    virtual void windowReceivedMessage(HWND, UINT message, WPARAM, LPARAM);

    RECT m_rect;
    HWND m_window;
    HWND m_topLevelParentWindow;
    HWND m_toolTipWindow;

    HCURSOR m_lastCursorSet;
    HCURSOR m_webCoreCursor;
    HCURSOR m_overrideCursor;

    bool m_trackingMouseLeave;
    bool m_isBeingDestroyed;

    RefPtr<WebPageProxy> m_page;
};

WebView::WebView(RECT rect, WebPageNamespace* pageNamespace, HWND parentWindow)
    : m_rect(rect)
    , m_topLevelParentWindow(0)
    , m_toolTipWindow(0)
    , m_lastCursorSet(0)
    , m_webCoreCursor(0)
    , m_overrideCursor(0)
    , m_trackingMouseLeave(false)
    , m_isBeingDestroyed(false)
{
    registerWebViewWindowClass();

    m_page = pageNamespace->createWebPage();
    m_page->setPageClient(this);
    m_page->setDrawingArea(ChunkedUpdateDrawingAreaProxy::create(this));

    m_window = ::CreateWindowEx(0, kWebKit2WebViewWindowClassName, 0, WS_CHILD | WS_CLIPSIBLINGS | WS_CLIPCHILDREN,
        rect.top, rect.left, rect.right - rect.left, rect.bottom - rect.top, parentWindow ? parentWindow : HWND_MESSAGE, 0, instanceHandle(), this);
    ASSERT(::IsWindow(m_window));

    m_page->initializeWebPage(IntRect(rect).size());

    ::ShowWindow(m_window, SW_SHOW);

    // FIXME: Initializing the tooltip window here matches WebKit win, but seems like something
    // we could do on demand to save resources.
    initializeToolTipWindow();

    // Initialize the top level parent window and register it with the WindowMessageBroadcaster.
    windowAncestryDidChange();
}

WebView has a native window handle (HWND) and a reference to a WebPageProxy object which is also initialized here. It has a DrawingAreaProxy as a member. Sometimes it receives an inter-process draw message via WebPageProxy::didReceiveMessage. DrawingAreaProxy is the proxy in the UI Process to the DrawingArea object in a Web Process.

void WebPageProxy::didReceiveMessage(CoreIPC::Connection* connection, CoreIPC::MessageID messageID, CoreIPC::ArgumentDecoder* arguments)
{
    if (messageID.is<CoreIPC::MessageClassDrawingAreaProxy>()) {
        m_drawingArea->didReceiveMessage(connection, messageID, arguments);
        return;
    }

    didReceiveWebPageProxyMessage(connection, messageID, arguments);
}

From here on, I’ll show you what the graphics update loop is like in WebKit2. You’d notice that in WebView::WebView the WebPageProxy object is initialized with ChunkedUpdateDrawingAreaProxy as its DrawingAreaProxy object. It is the default drawing strategy for the Windows version. It is a proxy to a ChunkedUpdateDrawingArea object in a Web Process.

ChunkedUpdateDrawingArea::ChunkedUpdateDrawingArea(DrawingAreaID identifier, WebPage* webPage)
    : DrawingArea(ChunkedUpdateDrawingAreaType, identifier, webPage)
    , m_isWaitingForUpdate(false)
    , m_paintingIsSuspended(false)
    , m_displayTimer(WebProcess::shared().runLoop(), this, &ChunkedUpdateDrawingArea::display)
{
}

// snip

void ChunkedUpdateDrawingArea::scheduleDisplay()
{
    if (m_paintingIsSuspended)
        return;

    if (m_isWaitingForUpdate)
        return;

    if (m_dirtyRect.isEmpty())
        return;

    if (m_displayTimer.isActive())
        return;

    m_displayTimer.startOneShot(0);
}

It schedules the first update of the drawing area by pushing the ChunkedUpdateDrawingArea::display function into the RunLoop.

void ChunkedUpdateDrawingArea::display()
{
    ASSERT(!m_isWaitingForUpdate);

    if (m_paintingIsSuspended)
        return;

    if (m_dirtyRect.isEmpty())
        return;

    // Layout if necessary.
    m_webPage->layoutIfNeeded();

    IntRect dirtyRect = m_dirtyRect;
    m_dirtyRect = IntRect();

    // Create a new UpdateChunk and paint into it.
    UpdateChunk updateChunk(dirtyRect);
    paintIntoUpdateChunk(&updateChunk);

    WebProcess::shared().connection()->send(DrawingAreaProxyMessage::Update, m_webPage->pageID(), CoreIPC::In(updateChunk));

    m_isWaitingForUpdate = true;
    m_displayTimer.stop();
}

When there is a dirty rect as the result of modified page layout, it creates an UpdateChunk object. The Windows version of UpdateChunk is a shared memory bitmap created with the CreateFileMapping API to make it accessible from multiple processes. Then the content of the dirty rect is written into the bitmap with ChunkedUpdateDrawingArea::paintIntoUpdateChunk.

UpdateChunk::UpdateChunk(const IntRect& rect)
    : m_rect(rect)
{
    // Create our shared memory mapping.
    unsigned memorySize = rect.height() * rect.width() * 4;
    m_bitmapSharedMemory = ::CreateFileMapping(INVALID_HANDLE_VALUE, 0, PAGE_READWRITE, 0, memorySize, 0);
}

void ChunkedUpdateDrawingArea::paintIntoUpdateChunk(UpdateChunk* updateChunk)
{
    OwnPtr<HDC> hdc(::CreateCompatibleDC(0));

    void* bits;
    BitmapInfo bmp = BitmapInfo::createBottomUp(updateChunk->rect().size());
    OwnPtr<HBITMAP> hbmp(::CreateDIBSection(0, &bmp, DIB_RGB_COLORS, &bits, updateChunk->memory(), 0));

    HBITMAP hbmpOld = static_cast<HBITMAP>(::SelectObject(hdc.get(), hbmp.get()));

    GraphicsContext gc(hdc.get());
    gc.save();

    // FIXME: Is this white fill needed?
    RECT rect = updateChunk->rect();
    ::FillRect(hdc.get(), &rect, (HBRUSH)::GetStockObject(WHITE_BRUSH));
    gc.translate(-updateChunk->rect().x(), -updateChunk->rect().y());

    m_webPage->drawRect(gc, updateChunk->rect());

    gc.restore();

    // Re-select the old HBITMAP
    ::SelectObject(hdc.get(), hbmpOld);
}

When it’s done, the DrawingAreaProxyMessage::Update IPC message is sent to the ChunkedUpdateDrawingAreaProxy in the UI Process with the bitmap created. It receives the message in ChunkedUpdateDrawingAreaProxy::didReceiveMessage and decodes the bitmap packed as an IPC payload.

void ChunkedUpdateDrawingAreaProxy::update(UpdateChunk* updateChunk)
{
    if (!m_isVisible) {
        // We got an update request that must have been sent before we told the web process to suspend painting.
        // Don't paint this into the backing store, because that could leave the backing store in an inconsistent state.
        // Instead, we will just tell the drawing area to repaint everything when we resume painting.
        m_forceRepaintWhenResumingPainting = true;
    } else {
        // Just paint into backing store.
        drawUpdateChunkIntoBackingStore(updateChunk);
    }

    WebPageProxy* page = this->page();
    page->process()->send(DrawingAreaMessage::DidUpdate, page->pageID(), CoreIPC::In(info().id));
}

void ChunkedUpdateDrawingAreaProxy::didReceiveMessage(CoreIPC::Connection*, CoreIPC::MessageID messageID, CoreIPC::ArgumentDecoder* arguments)
{
    switch (messageID.get<DrawingAreaProxyMessage::Kind>()) {
        case DrawingAreaProxyMessage::Update: {
            UpdateChunk updateChunk;
            if (!arguments->decode(updateChunk))
                return;

            update(&updateChunk);
            break;
        }
        case DrawingAreaProxyMessage::DidSetSize: {
            UpdateChunk updateChunk;
            if (!arguments->decode(CoreIPC::Out(updateChunk)))
                return;

            didSetSize(&updateChunk);
            break;
        }
        default:
            ASSERT_NOT_REACHED();
    }
}

Then, in ChunkedUpdateDrawingAreaProxy::update it calls ChunkedUpdateDrawingAreaProxy::drawUpdateChunkIntoBackingStore to BitBlt from the updated image to the backing store.

void ChunkedUpdateDrawingAreaProxy::drawUpdateChunkIntoBackingStore(UpdateChunk* updateChunk)
{
    ensureBackingStore();

    OwnPtr<HDC> updateChunkBitmapDC(::CreateCompatibleDC(m_backingStoreDC.get()));

    // Create a bitmap.
    BitmapInfo bitmapInfo = BitmapInfo::createBottomUp(updateChunk->rect().size());

    // Duplicate the update chunk handle.
    HANDLE updateChunkHandle;
    BOOL result = ::DuplicateHandle(m_webView->page()->process()->processIdentifier(), updateChunk->memory(),
                                    ::GetCurrentProcess(), &updateChunkHandle, STANDARD_RIGHTS_REQUIRED | FILE_MAP_READ | FILE_MAP_WRITE, false, DUPLICATE_CLOSE_SOURCE);

    void* pixels = 0;
    OwnPtr<HBITMAP> hBitmap(::CreateDIBSection(0, &bitmapInfo, DIB_RGB_COLORS, &pixels, updateChunkHandle, 0));
    ::SelectObject(updateChunkBitmapDC.get(), hBitmap.get());

    // BitBlt from the UpdateChunk to the backing store.
    ::BitBlt(m_backingStoreDC.get(), updateChunk->rect().x(), updateChunk->rect().y(), updateChunk->rect().width(), updateChunk->rect().height(), updateChunkBitmapDC.get(), 0, 0, SRCCOPY);

    // FIXME: We should not do this here.
    ::CloseHandle(updateChunkHandle);

    // Invalidate the WebView's HWND.
    RECT rect = updateChunk->rect();
    ::InvalidateRect(m_webView->window(), &rect, false);
}

As the event notification, the DrawingAreaMessage::DidUpdate IPC message is sent to the Web Process which triggers a subsequent drawing operation.

Now the page view is ready. After that, in BrowserView::create, it sets application-defined callbacks with the WKPageSetPageUIClient API to invoke appropriate UI elements on events returned from WebKit.

WKPageUIClient uiClient = {
        0,              /* version */
        parentWindow,   /* clientInfo */
        createNewPage,
        showPage,
        closePage,
        runJavaScriptAlert,
        runJavaScriptConfirm,
        runJavaScriptPrompt,
        setStatusText,
        mouseDidMoveOverElement,
        0,          /* didNotHandleKeyEvent */
        0,          /* toolbarsAreVisible */
        0,          /* setToolbarsAreVisible */
        0,          /* menuBarIsVisible */
        0,          /* setMenuBarIsVisible */
        0,          /* statusBarIsVisible */
        0,          /* setStatusBarIsVisible */
        0,          /* isResizable */
        0,          /* setIsResizable */
        0,          /* getWindowFrame */
        0,          /* setWindowFrame */
        0,          /* runBeforeUnloadConfirmPanel */
        0,          /* didDraw */
        0           /* pageDidScroll */
    };

    WKPageSetPageUIClient(WKViewGetPage(m_webView), &uiClient);

Though this article uses the Windows version as the primary example, the Mac version of MiniBrowser in Objective-C has more features implemented already by using other WebKit2 APIs. Besides WKPageUIClient, WKPage.h offers other kinds of clients such as WKPageLoaderClient, WKPagePolicyClient and WKPageFindClient for embedders to customize the application behavior by defining and plugging in their own callback functions.

As for other multiprocess-related implementation details, the Web Process has a VisitedLinkTable object as its member. Its hash table is on the SharedMemory object for cross-process update.

Examples of WebKit2 usage are also found in the tests for the WebKit2 API so browse them if you are interested.

Since WebKit2 is in its very early stage, the code size is still kept compact so reading its source code and comprehending its structure is super easy and fun. Going back to my original question at the beginning of this article, it seems the basic functions of WebKit2 are all in after 6 months. Though my personal attention has been on Chromium development rather than on WebKit, it may be interesting to see how these 2 interact each other in future.

My interest in libevent comes from my own program, DICE. From the beginning of the development in 2002, its I/O is fully optimized to Windows and I/O Completion Ports (IOCP) without using any middleware or libraries. It’s old and not often updated, but works flawlessly. However, replacing it with a decent OSS library can be a good chance to make it more simple and robust. The concern from the performance point of view is the only obstacle left, but libevent 2 is supposed to come with the IOCP support. That was the news that let me start the evaluation.

The libevent version for this article is 2.0.7 RC. I built it with Visual Studio 2010 (VC10). Since I wanted to use the debugger to trace its flow, I built it as the debug version by changing the CFLAGS compiler options /Ox to /Od /MDd /Zi in the Makefile.nmake in the main directory and the test directory. ‘nmake -f Makefile.nmake‘ produces the libevent.lib static library.

Before building a project with libevent, you need to manually copy WIN32-Code\event2\event-config.h to include\event2\event-config.h. Then add libevent.lib to the linker input (if you use socket, ws2_32.lib too), and add libevent and libevent\include directories to the include directory.

Then I wrote a test code with its evhttp ‘Event-driven HTTP servers’ functions. It’s a simple Web server that shows requested URI and quits if /quit is requested. It listens to the port 8080.

#include <iostream>
#include <cmath>
#include <ctime>

#include <event.h>
#include <evhttp.h>
#include <event2/thread.h>

void handlerRoot(evhttp_request* request, void* args)
{
	std::cout << "Request URI: " << request->uri << std::endl;

	evbuffer* buffer = evbuffer_new();

	evkeyvalq* headers = evhttp_request_get_output_headers(request);
	evhttp_add_header(headers, "Content-Type", "text/html; charset=UTF-8");
	evbuffer_add_printf(buffer, "Request URI: %s", request->uri);

	evhttp_send_reply(request, HTTP_OK, "OK", buffer);

	evbuffer_free(buffer);
}

void handlerQuit(evhttp_request* request, void* args)
{
	event_base* eventBase = (event_base*)args;
	event_base_loopbreak(eventBase);
}

int _tmain(int argc, _TCHAR* argv[])
{
	WSADATA wsaData = {0};
	::WSAStartup(MAKEWORD(2, 2), &wsaData);

	event_config* eventConfig = event_config_new();
	event_config_set_flag(eventConfig, EVENT_BASE_FLAG_STARTUP_IOCP);
	event_config_set_num_cpus_hint(eventConfig, 8);

	event_base* eventBase = event_base_new_with_config(eventConfig);

	evthread_use_windows_threads();

	evhttp* eventHttp = evhttp_new(eventBase);

	evhttp_set_gencb(eventHttp, handlerRoot, eventBase);
	evhttp_set_cb(eventHttp, "/quit", handlerQuit, eventBase);

	evhttp_bind_socket(eventHttp, "0.0.0.0", 8080);

	timeval tv = {::pow(2.0, 31) - ::time(NULL) - 1000, 0};

	event_base_loopexit(eventBase, &tv);

	event_base_dispatch(eventBase);

	evhttp_free(eventHttp);
	event_base_free(eventBase);

	::WSACleanup();

	return 0;
}

The document is not yet complete for the recently added functions and I had to read the libevent code to add some function calls that enable IOCP. As the whatsnew-2.0.txt suggests, it’s disabled by default. The wierdest part is probably this:

	timeval tv = {::pow(2.0, 31) - ::time(NULL) - 1000, 0};

	event_base_loopexit(eventBase, &tv);

	event_base_dispatch(eventBase);

event_base_dispatch starts the event dispatching loop, but if you enable IOCP it doesn’t block and the program just exits. So you have to manually set its lifetime. I tried to set the largest signed integer (::pow(2.0, 31)), but unfortunately event_base_loopexit internally calls event_base_once which calls event_add_internal with tv_is_absolute = 0. The tricky code above is just a quick fix.

/* Implementation function to add an event.  Works just like event_add,
 * except: 1) it requires that we have the lock.  2) if tv_is_absolute is set,
 * we treat tv as an absolute time, not as an interval to add to the current
 * time */
static inline int
event_add_internal(struct event *ev, const struct timeval *tv,
    int tv_is_absolute)
{

event_config_set_num_cpus_hint sets the CPU number as 8, it’s because I use Core i7 with 8 SMT threads. Internally, it spawns (num_cpus * 2) threads in its thread pool for IOCP.

struct event_iocp_port *
event_iocp_port_launch(int n_cpus)
{
	struct event_iocp_port *port;
	int i;

	if (!extension_fns_initialized)
		init_extension_functions(&the_extension_fns);

	if (!(port = mm_calloc(1, sizeof(struct event_iocp_port))))
		return NULL;

	if (n_cpus <= 0)
		n_cpus = N_CPUS_DEFAULT;
	port->n_threads = n_cpus * 2;
	port->threads = calloc(port->n_threads, sizeof(HANDLE));
	if (!port->threads)
		goto err;

	port->port = CreateIoCompletionPort(INVALID_HANDLE_VALUE, NULL, 0,
			n_cpus);
	port->ms = -1;
	if (!port->port)
		goto err;

	port->shutdownSemaphore = CreateSemaphore(NULL, 0, 1, NULL);
	if (!port->shutdownSemaphore)
		goto err;

	for (i=0; i<port->n_threads; ++i) {
		ev_uintptr_t th = _beginthread(loop, 0, port);
		if (th == (ev_uintptr_t)-1)
			goto err;
		port->threads[i] = (HANDLE)th;
		++port->n_live_threads;
	}

	InitializeCriticalSectionAndSpinCount(&port->lock, 1000);

	return port;
err:
	if (port->port)
		CloseHandle(port->port);
	if (port->threads)
		mm_free(port->threads);
	if (port->shutdownSemaphore)
		CloseHandle(port->shutdownSemaphore);
	mm_free(port);
	return NULL;
}

The threads in the pool then block with GetQueuedCompletionStatus that waits for I/O completion notification.

static void
loop(void *_port)
{
	struct event_iocp_port *port = _port;
	long ms = port->ms;
	HANDLE p = port->port;

	if (ms <= 0)
		ms = INFINITE;

	while (1) {
		OVERLAPPED *overlapped=NULL;
		ULONG_PTR key=0;
		DWORD bytes=0;
		int ok = GetQueuedCompletionStatus(p, &bytes, &key,
			&overlapped, ms);
		EnterCriticalSection(&port->lock);
		if (port->shutdown) {
			if (--port->n_live_threads == 0)
				ReleaseSemaphore(port->shutdownSemaphore, 1,
						NULL);
			LeaveCriticalSection(&port->lock);
			return;
		}
		LeaveCriticalSection(&port->lock);

		if (key != NOTIFICATION_KEY && overlapped)
			handle_entry(overlapped, key, bytes, ok);
		else if (!overlapped)
			break;
	}
	event_warnx("GetQueuedCompletionStatus exited with no event.");
	EnterCriticalSection(&port->lock);
	if (--port->n_live_threads == 0)
		ReleaseSemaphore(port->shutdownSemaphore, 1, NULL);
	LeaveCriticalSection(&port->lock);
}

So I built the above code and ran it. It worked. But when I set breakpoints in the debugger, it turned out that things were not working as expected. It breaks at the line after GetQueuedCompletionStatus only when accepting a new connection. I suspected only the accept operation was overlapped.

static int
start_accepting(struct accepting_socket *as)
{
	/* requires lock */
	const struct win32_extension_fns *ext = event_get_win32_extension_fns();
	DWORD pending = 0;
	SOCKET s = socket(as->family, SOCK_STREAM, 0);
	if (s == INVALID_SOCKET)
		return -1;

	setsockopt(s, SOL_SOCKET, SO_UPDATE_ACCEPT_CONTEXT,
	    (char *)&as->lev->fd, sizeof(&as->lev->fd));

	if (!(as->lev->base.flags & LEV_OPT_LEAVE_SOCKETS_BLOCKING))
		evutil_make_socket_nonblocking(s);

	if (event_iocp_port_associate(as->lev->port, s, 1) < 0) {
		closesocket(s);
		return -1;
	}

	as->s = s;

	if (ext->AcceptEx(as->lev->fd, s, as->addrbuf, 0,
		as->buflen/2, as->buflen/2, &pending, &as->overlapped.overlapped))
	{
		/* Immediate success! */
		accepted_socket_cb(&as->overlapped, 1, 0, 1);
	} else {
		int err = WSAGetLastError();
		if (err != ERROR_IO_PENDING) {
			event_warnx("AcceptEx: %s", evutil_socket_error_to_string(err));
			return -1;
		}
	}

	return 0;
}

In the debugger, it surely calls AcceptEx in start_accepting. The problem is, it uses the non-IOCP version of the read operation function.

evbuffer_read(struct evbuffer *buf, evutil_socket_t fd, int howmuch)
{
// snip

#ifdef WIN32
		{
			DWORD bytesRead;
			DWORD flags=0;
			if (WSARecv(fd, vecs, nvecs, &bytesRead, &flags, NULL, NULL)) {
				/* The read failed. It might be a close,
				 * or it might be an error. */
				if (WSAGetLastError() == WSAECONNABORTED)
					n = 0;
				else
					n = -1;
			} else
				n = bytesRead;
		}
#else
		n = readv(fd, vecs, nvecs);
#endif

int
evbuffer_launch_read(struct evbuffer *buf, size_t at_most,
		struct event_overlapped *ol)
{
// snip

	_evbuffer_incref(buf);
	if (WSARecv(buf_o->fd, buf_o->buffers, nvecs, &bytesRead, &flags,
		    &ol->overlapped, NULL)) {
		int error = WSAGetLastError();
		if (error != WSA_IO_PENDING) {
			/* An actual error. */
			pin_release(buf_o, EVBUFFER_MEM_PINNED_R);
			evbuffer_unfreeze(buf, 0);
			evbuffer_free(buf); /* decref */
			goto done;
		}
	}

The latter one gives an OVERLAPPED structure to initiate overlapped read, but it was not actually called.

I tracked where it went wrong. The culprit was in http.c. It used the bufferevent_new that doesn’t support IOCP.

struct evhttp_connection *
evhttp_connection_base_new(struct event_base *base, struct evdns_base *dnsbase,
    const char *address, unsigned short port)
{
// snip

	if ((evcon->bufev = bufferevent_new(-1,
		    evhttp_read_cb,
		    evhttp_write_cb,
		    evhttp_error_cb, evcon)) == NULL) {
		event_warn("%s: bufferevent_new failed", __func__);
		goto error;
	}

Instead, it has to use bufferevent_socket_new. But other parts of http.c have to be modified to work correctly, so I gave up there.

struct bufferevent *
bufferevent_socket_new(struct event_base *base, evutil_socket_t fd,
    int options)
{
	struct bufferevent_private *bufev_p;
	struct bufferevent *bufev;

#ifdef WIN32
	if (base && event_base_get_iocp(base))
		return bufferevent_async_new(base, fd, options);
#endif

Though my time ran out, you may test if the async read/write does work or not by running the iocp/bufferevent_async and other regression tests defined in regress_iocp.c in the test folder. Don’t forget to add the --no-fork option.

Will it be improved? I hope so, these IOCP details should be hidden from a user.

Another thing to look at is the thread pool. Since Windows 2000, the thread pool is an OS component that is optimized to the OS inner working. BindIoCompletionCallback is available since Windows 2000, and CreateThreadpool and other related API have been added in Windows Vista. It seems it’s still far away that libevent is fully optimized to Windows.

However, as an easy-going framework to save time, it’s in a good state already as shown in my example. A bit more polishing will make it shine.

結果から先に述べると、若干手間を要するものの問題なくビルドでき、closureも利用できた。ここでいうclosureとは、呼び出された際にユーザー指定コールバック関数(元の呼び出しに使われたlibffiフォーマットの引数データが渡ってくる)を起動してくれる関数コードを、ユーザーが動的に指定したシグニチャで、ランタイムに実行可能メモリ上に構築してくれるlibffiのAPIが用意されているので、それを利用して作成したバイナリコードを指す。

js-ctypes実装の構造は至極直截的で、JSのオブジェクトとネイティブオブジェクトのバインダとしてのCTypesクラスと、dll/so/dylibみたいなバイナリコンポーネントのラッパーのLibraryクラスから成っている。Library::Declareでシンボルからバイナリ内の関数アドレスを得るときは、PR_FindFunctionSymbolを呼ぶ。これはNSPRの関数で、Windows上では、なんのことはないGetProcAddressが呼ばれる。なんでlibffiなんてものが必要かというと、荒っぽく言ってしまえば、Cでは関数ポインタを宣言しておけばコンパイラが良きに計らってくれるところ、動的言語で同じことをランタイムに行うために、その辺の呼び出し規約上のお膳立てをlibffiが整えてくれるというわけだ。

上述のclosureは、js-ctypesでは、ネイティブコード側にJavascriptの関数をコールバックとして渡す時に利用されている。Javascript関数オブジェクトに関連づけたclosureを作成し、それが呼び出された場合にはCClosure::ClosureStubが呼び出され、関連づけられていたJavascript関数オブジェクトが実行されるようになっている。closureは、コールバック用のプロキシとして働いており、この利用法自体は、libffiの実装内でffi_prep_closure_locの実体がFFI_INIT_TRAMPOLINE呼び出しで、closure用のメモリ領域が「トランポリン」と呼ばれていることからわかるように、想定の範囲内と言える。

Windowsアプリのメッセージハンドラ=ウィンドウプロシージャとしておなじみのWindowProcコールバックは、js-ctypesでは以下のように表現される。

var WNDPROC = ctypes.FunctionType(ctypes.stdcall_abi, ctypes.int, [ctypes.voidptr_t, ctypes.int32_t, ctypes.int32_t, ctypes.int32_t]).ptr;

Windows APIの呼び出し規約はWINAPI(__stdcall)なのでstdcall_abiが指定されている。これを元にしてlibffiがclosureを作成し、closureが起動されるとjs-ctypesが再度Javascriptの関数に戻して実行してやる。これが何を意味するかというと、js-ctypesがあればJavascriptでWindowsアプリのイベント駆動モデルすらも代替できる、つまりMFCとかイラネーよなということになる。これだけ強力なら、Firefox 4のGecko 2がfrozenインターフェイスを破棄してjs-ctypesを媒介にXPCOMを脱構築するという流れも必然であると納得できる。

Windows上でのVisual Studio 2010(VC10)を使ったlibffiのビルド手順としては、以下になる:

1. Cygwinをインストール。デフォルトのパッケージに加え、Develのmakeが必要なので含めておく。(msysはcygpathが無いので駄目)
2. Gitをインストール。改行コードの扱いは、チェックアウト=as-is、チェックイン=LFで。cygwinのshは、configureやconfig.sub等のスクリプトが改行コードLFでないと処理できないため。
3. GitでlibffiのGitHubレポジトリからソース取得。
4. Visual StudioのVisual Studio Toolsからコマンドプロンプトを起動。Cygwinのフォルダに移動し、Cygwin.batを起動。bash内で/cygdrive/の中のlibffiのソースが置いてあるディレクトリへ移動。
5. configureオプションについては、libffiのREADME内に簡単な指示はあるものの、Firefoxでのjs-ctypes用configure.inを参考にすべきだろう。

   # Build jsctypes if it's enabled.
   if test "$JS_HAS_CTYPES"; then
     # Run the libffi 'configure' script.
     ac_configure_args="--disable-shared --enable-static --disable-raw-api"
     if test "$MOZ_DEBUG"; then
       ac_configure_args="$ac_configure_args --enable-debug"
     fi
     if test "$DSO_PIC_CFLAGS"; then
       ac_configure_args="$ac_configure_args --with-pic"
     fi
     if test "$CROSS_COMPILE"; then
       case "$target" in
       *-mingw*)
         ac_configure_args="$ac_configure_args --build=$build --host=${target_cpu}-${target_os} HOST_CC=\"$HOST_CC\" CC=\"$CC\""
         ;;
       *-android*)
         CFLAGS="$ANDROID_CFLAGS"
         CPPFLAGS="$ANDROID_CPPFLAGS"
         LDFLAGS="$ANDROID_LDFLAGS"
   
         export AS CC CXX CPP LD AR RANLIB STRIP CPPFLAGS CFLAGS LDFLAGS
   
         ac_configure_args="$ac_configure_args --build=$build --host=${target_cpu}-${target_os} HOST_CC=\"$HOST_CC\""
         ;;
       *)
         ac_configure_args="$ac_configure_args --build=$build --host=$target HOST_CC=\"$HOST_CC\" CC=\"$CC\""
         ;;
       esac
     fi
     if test "$_MSC_VER"; then
       # Use a wrapper script for cl and ml that looks more like gcc.
       # autotools can't quite handle an MSVC build environment yet.
       ac_configure_args="$ac_configure_args LD=link CPP=\"cl -nologo -EP\" SHELL=sh.exe"
       case "${target_cpu}" in
       x86_64)
         # Need target since MSYS tools into mozilla-build may be 32bit
         ac_configure_args="$ac_configure_args CC=\"$_topsrcdir/ctypes/libffi/msvcc.sh -m64\" --build=$build --host=$target"
         ;;
       *)
         ac_configure_args="$ac_configure_args CC=$_topsrcdir/ctypes/libffi/msvcc.sh"
         ;;
       esac
     fi
     if test "$SOLARIS_SUNPRO_CC"; then
       # Always use gcc for libffi on Solaris
       if test ! "$HAVE_64BIT_OS"; then
         ac_configure_args="$ac_configure_args CC=gcc CFLAGS=-m32"
       else
         ac_configure_args="$ac_configure_args CC=gcc CFLAGS=-m64"
       fi
     fi
     if test "$OS_ARCH" = "OS2"; then
       ac_configure_args="$ac_configure_args CFLAGS=-Zomf AR=emxomfar"
     fi
     if test -n "$MOZ_THUMB2"; then
       ac_configure_args="$ac_configure_args --enable-thumb2"
     fi
   
     # Use a separate cache file for libffi, since it does things differently
     # from our configure.
     mkdir -p $_objdir/ctypes/libffi
     old_cache_file=$cache_file
     cache_file=$_objdir/ctypes/libffi/config.cache
     old_config_files=$CONFIG_FILES
     unset CONFIG_FILES
     AC_OUTPUT_SUBDIRS(ctypes/libffi)
     cache_file=$old_cache_file
     ac_configure_args="$_SUBDIR_CONFIG_ARGS"
     CONFIG_FILES=$old_config_files
   fi
   

   リリース版は
   ./configure --disable-shared --enable-static CC=./msvcc.sh LD=link CPP="cl -nologo -EP"
   デバッグ版は
   ./configure --disable-shared --enable-static --enable-debug CC=./msvcc.sh LD=link CPP="cl -nologo -EP"

6. ここでmakeしようとすると以下のエラーに遭遇する:
   

   makelibtool: compile: ./msvcc.sh -DHAVE_CONFIG_H -I. -I. -I./include -Iinclude -I./
src -Wall -g -fexceptions -O2 -c src\\debug.c -DDLL_EXPORT -DPIC
cl -MD -nologo -W3 -DHAVE_CONFIG_H -I. -I. -I./include -Iinclude -I./src -Zi -DE
BUG -O2 -OPT:REF -OPT:ICF -INCREMENTAL:NO -c src\debug.c -DDLL_EXPORT -DPIC
cl : コマンド ライン warning D9002 : 不明なオプション '-OP' を無視します
cl : コマンド ライン warning D9002 : 不明なオプション '-OT' を無視します
cl : コマンド ライン warning D9002 : 不明なオプション '-O:' を無視します
cl : コマンド ライン warning D9002 : 不明なオプション '-OR' を無視します
cl : コマンド ライン warning D9002 : 不明なオプション '-OE' を無視します
cl : コマンド ライン warning D9002 : 不明なオプション '-OF' を無視します
cl : コマンド ライン warning D9002 : 不明なオプション '-OP' を無視します
cl : コマンド ライン warning D9002 : 不明なオプション '-OT' を無視します
cl : コマンド ライン warning D9002 : 不明なオプション '-O:' を無視します
cl : コマンド ライン warning D9002 : 不明なオプション '-OI' を無視します
cl : コマンド ライン warning D9002 : 不明なオプション '-OC' を無視します
cl : コマンド ライン warning D9002 : 不明なオプション '-OF' を無視します
srcdebug.c
c1 : fatal error C1083: ソース ファイルを開けません。'srcdebug.c': No such file or directory

   どうやらsrc\debug.cのバックスラッシュがおかしいというのがわかるので、libtool内の

   # Fix the shell variable $srcfile for the compiler.
   fix_srcfile_path="\`cygpath -w \"\$srcfile\"\`"
   

   の-wを-uに変更

7. ここでmakeしようとすると今度は以下のエラーに遭遇する:
   

   E:\program\src\libffi\libffi-github\include\ffitarget.h : warning C4819: ファイ
ルは、現在のコード ページ (932) で表示できない文字を含んでいます。データの損失を
防ぐために、ファイルを Unicode 形式で保存してください。
E:\program\src\libffi\libffi-github\include\ffitarget.h(1) : error C2059: 構文エ
ラー : '!'
c:\program files (x86)\microsoft visual studio 10.0\vc\include\codeanalysis\sour
ceannotations.h(91) : error C2061: 構文エラー : 識別子 'size_t'
c:\program files (x86)\microsoft visual studio 10.0\vc\include\codeanalysis\sour
ceannotations.h(92) : error C2061: 構文エラー : 識別子 'ValidBytesConst'
c:\program files (x86)\microsoft visual studio 10.0\vc\include\codeanalysis\sour
ceannotations.h(92) : error C2059: 構文エラー : ';'
c:\program files (x86)\microsoft visual studio 10.0\vc\include\codeanalysis\sour
ceannotations.h(97) : error C2061: 構文エラー : 識別子 'WritableElementsConst'
c:\program files (x86)\microsoft visual studio 10.0\vc\include\codeanalysis\sour
ceannotations.h(97) : error C2059: 構文エラー : ';'
c:\program files (x86)\microsoft visual studio 10.0\vc\include\codeanalysis\sour
ceannotations.h(98) : error C2061: 構文エラー : 識別子 'WritableBytesConst'
c:\program files (x86)\microsoft visual studio 10.0\vc\include\codeanalysis\sour
ceannotations.h(98) : error C2059: 構文エラー : ';'
c:\program files (x86)\microsoft visual studio 10.0\vc\include\codeanalysis\sour
ceannotations.h(103) : error C2061: 構文エラー : 識別子 'ElementSizeConst'
c:\program files (x86)\microsoft visual studio 10.0\vc\include\codeanalysis\sour
ceannotations.h(103) : error C2059: 構文エラー : ';'
c:\program files (x86)\microsoft visual studio 10.0\vc\include\codeanalysis\sour
ceannotations.h(107) : error C2059: 構文エラー : '}'
c:\program files (x86)\microsoft visual studio 10.0\vc\include\codeanalysis\sour
ceannotations.h(122) : error C2061: 構文エラー : 識別子 'size_t'
c:\program files (x86)\microsoft visual studio 10.0\vc\include\codeanalysis\sour
ceannotations.h(123) : error C2061: 構文エラー : 識別子 'ValidBytesConst'
c:\program files (x86)\microsoft visual studio 10.0\vc\include\codeanalysis\sour
ceannotations.h(123) : error C2059: 構文エラー : ';'
c:\program files (x86)\microsoft visual studio 10.0\vc\include\codeanalysis\sour
ceannotations.h(128) : error C2061: 構文エラー : 識別子 'WritableElementsConst'
c:\program files (x86)\microsoft visual studio 10.0\vc\include\codeanalysis\sour
ceannotations.h(128) : error C2059: 構文エラー : ';'
c:\program files (x86)\microsoft visual studio 10.0\vc\include\codeanalysis\sour
ceannotations.h(129) : error C2061: 構文エラー : 識別子 'WritableBytesConst'
c:\program files (x86)\microsoft visual studio 10.0\vc\include\codeanalysis\sour
ceannotations.h(129) : error C2059: 構文エラー : ';'
c:\program files (x86)\microsoft visual studio 10.0\vc\include\codeanalysis\sour
ceannotations.h(134) : error C2061: 構文エラー : 識別子 'ElementSizeConst'
c:\program files (x86)\microsoft visual studio 10.0\vc\include\codeanalysis\sour
ceannotations.h(134) : error C2059: 構文エラー : ';'
c:\program files (x86)\microsoft visual studio 10.0\vc\include\codeanalysis\sour
ceannotations.h(139) : error C2059: 構文エラー : '}'
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\crtdefs.h(409) :
error C2061: 構文エラー : 識別子 'rsize_t'
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\crtdefs.h(409) :
error C2059: 構文エラー : ';'
E:\program\src\libffi\libffi-github\include\ffi.h(97) : error C2016: C では、構
造体または共用体に少なくとも 1 つのメンバーが必要です。
E:\program\src\libffi\libffi-github\include\ffi.h(97) : error C2061: 構文エラー
: 識別子 'size_t'
E:\program\src\libffi\libffi-github\include\ffi.h(101) : error C2059: 構文エラー
: '}'
E:\program\src\libffi\libffi-github\include\ffi.h(153) : error C2061: 構文エラー
: 識別子 'ffi_type_void'
E:\program\src\libffi\libffi-github\include\ffi.h(153) : error C2059: 構文エラー
: ';'
E:\program\src\libffi\libffi-github\include\ffi.h(154) : error C2061: 構文エラー
: 識別子 'ffi_type_uint8'
E:\program\src\libffi\libffi-github\include\ffi.h(154) : error C2059: 構文エラー
: ';'
E:\program\src\libffi\libffi-github\include\ffi.h(155) : error C2061: 構文エラー
: 識別子 'ffi_type_sint8'
E:\program\src\libffi\libffi-github\include\ffi.h(155) : error C2059: 構文エラー
: ';'
E:\program\src\libffi\libffi-github\include\ffi.h(156) : error C2061: 構文エラー
: 識別子 'ffi_type_uint16'
E:\program\src\libffi\libffi-github\include\ffi.h(156) : error C2059: 構文エラー
: ';'
E:\program\src\libffi\libffi-github\include\ffi.h(157) : error C2061: 構文エラー
: 識別子 'ffi_type_sint16'
E:\program\src\libffi\libffi-github\include\ffi.h(157) : error C2059: 構文エラー
: ';'
E:\program\src\libffi\libffi-github\include\ffi.h(158) : error C2061: 構文エラー
: 識別子 'ffi_type_uint32'
E:\program\src\libffi\libffi-github\include\ffi.h(158) : error C2059: 構文エラー
: ';'
E:\program\src\libffi\libffi-github\include\ffi.h(159) : error C2061: 構文エラー
: 識別子 'ffi_type_sint32'
E:\program\src\libffi\libffi-github\include\ffi.h(159) : error C2059: 構文エラー
: ';'
E:\program\src\libffi\libffi-github\include\ffi.h(160) : error C2061: 構文エラー
: 識別子 'ffi_type_uint64'
E:\program\src\libffi\libffi-github\include\ffi.h(160) : error C2059: 構文エラー
: ';'
E:\program\src\libffi\libffi-github\include\ffi.h(161) : error C2061: 構文エラー
: 識別子 'ffi_type_sint64'
E:\program\src\libffi\libffi-github\include\ffi.h(161) : error C2059: 構文エラー
: ';'
E:\program\src\libffi\libffi-github\include\ffi.h(162) : error C2061: 構文エラー
: 識別子 'ffi_type_float'
E:\program\src\libffi\libffi-github\include\ffi.h(162) : error C2059: 構文エラー
: ';'
E:\program\src\libffi\libffi-github\include\ffi.h(163) : error C2061: 構文エラー
: 識別子 'ffi_type_double'
E:\program\src\libffi\libffi-github\include\ffi.h(163) : error C2059: 構文エラー
: ';'
E:\program\src\libffi\libffi-github\include\ffi.h(164) : error C2061: 構文エラー
: 識別子 'ffi_type_pointer'
E:\program\src\libffi\libffi-github\include\ffi.h(164) : error C2059: 構文エラー
: ';'
E:\program\src\libffi\libffi-github\include\ffi.h(182) : error C2016: C では、構
造体または共用体に少なくとも 1 つのメンバーが必要です。
E:\program\src\libffi\libffi-github\include\ffi.h(182) : error C2061: 構文エラー
: 識別子 'ffi_abi'
E:\program\src\libffi\libffi-github\include\ffi.h(184) : error C2143: 構文エラー
: '{' が '*' の前にありません。
E:\program\src\libffi\libffi-github\include\ffi.h(185) : error C2143: 構文エラー
: '{' が '*' の前にありません。
E:\program\src\libffi\libffi-github\include\ffi.h(191) : error C2059: 構文エラー
: '}'
E:\program\src\libffi\libffi-github\include\ffi.h(208) : error C2016: C では、構
造体または共用体に少なくとも 1 つのメンバーが必要です。
E:\program\src\libffi\libffi-github\include\ffi.h(208) : error C2061: 構文エラー
: 識別子 'ffi_sarg'
E:\program\src\libffi\libffi-github\include\ffi.h(209) : error C2061: 構文エラー
: 識別子 'uint'
E:\program\src\libffi\libffi-github\include\ffi.h(209) : error C2059: 構文エラー
: ';'
E:\program\src\libffi\libffi-github\include\ffi.h(213) : error C2059: 構文エラー
: '}'
E:\program\src\libffi\libffi-github\include\ffi.h(226) : error C2061: 構文エラー
: 識別子 'ffi_java_raw'
E:\program\src\libffi\libffi-github\include\ffi.h(226) : error C2059: 構文エラー
: ';'
E:\program\src\libffi\libffi-github\include\ffi.h(230) : error C2143: 構文エラー
: ')' が '*' の前にありません。
E:\program\src\libffi\libffi-github\include\ffi.h(230) : error C2143: 構文エラー
: '{' が '*' の前にありません。
E:\program\src\libffi\libffi-github\include\ffi.h(231) : error C2059: 構文エラー
: '型'
E:\program\src\libffi\libffi-github\include\ffi.h(235) : error C2143: 構文エラー
: ')' が '*' の前にありません。
E:\program\src\libffi\libffi-github\include\ffi.h(235) : error C2143: 構文エラー
: '{' が '*' の前にありません。
E:\program\src\libffi\libffi-github\include\ffi.h(235) : error C2059: 構文エラー
: '型'
E:\program\src\libffi\libffi-github\include\ffi.h(235) : error C2059: 構文エラー
: ')'
E:\program\src\libffi\libffi-github\include\ffi.h(236) : error C2143: 構文エラー
: ')' が '*' の前にありません。
E:\program\src\libffi\libffi-github\include\ffi.h(236) : error C2143: 構文エラー
: '{' が '*' の前にありません。
E:\program\src\libffi\libffi-github\include\ffi.h(236) : error C2143: 構文エラー
: ';' が '*' の前にありません。
E:\program\src\libffi\libffi-github\include\ffi.h(236) : error C2059: 構文エラー
: '型'
E:\program\src\libffi\libffi-github\include\ffi.h(236) : error C2059: 構文エラー
: ')'
E:\program\src\libffi\libffi-github\include\ffi.h(237) : error C2061: 構文エラー
: 識別子 'ffi_raw_size'
E:\program\src\libffi\libffi-github\include\ffi.h(237) : error C2059: 構文エラー
: ';'
E:\program\src\libffi\libffi-github\include\ffi.h(237) : error C2143: 構文エラー
: ')' が '*' の前にありません。
E:\program\src\libffi\libffi-github\include\ffi.h(237) : error C2143: 構文エラー
: '{' が '*' の前にありません。
E:\program\src\libffi\libffi-github\include\ffi.h(237) : error C2059: 構文エラー
: ')'
E:\program\src\libffi\libffi-github\include\ffi.h(243) : error C2143: 構文エラー
: ')' が '*' の前にありません。
E:\program\src\libffi\libffi-github\include\ffi.h(243) : error C2143: 構文エラー
: '{' が '*' の前にありません。
E:\program\src\libffi\libffi-github\include\ffi.h(244) : error C2059: 構文エラー
: '型'
E:\program\src\libffi\libffi-github\include\ffi.h(248) : error C2143: 構文エラー
: ')' が '*' の前にありません。
E:\program\src\libffi\libffi-github\include\ffi.h(248) : error C2143: 構文エラー
: '{' が '*' の前にありません。
E:\program\src\libffi\libffi-github\include\ffi.h(248) : error C2059: 構文エラー
: '型'
E:\program\src\libffi\libffi-github\include\ffi.h(248) : error C2059: 構文エラー
: ')'
E:\program\src\libffi\libffi-github\include\ffi.h(249) : error C2143: 構文エラー
: ')' が '*' の前にありません。
E:\program\src\libffi\libffi-github\include\ffi.h(249) : error C2143: 構文エラー
: '{' が '*' の前にありません。
E:\program\src\libffi\libffi-github\include\ffi.h(249) : error C2143: 構文エラー
: ';' が '*' の前にありません。
E:\program\src\libffi\libffi-github\include\ffi.h(249) : error C2059: 構文エラー
: '型'
E:\program\src\libffi\libffi-github\include\ffi.h(249) : error C2059: 構文エラー
: ')'
E:\program\src\libffi\libffi-github\include\ffi.h(250) : error C2061: 構文エラー
: 識別子 'ffi_java_raw_size'
E:\program\src\libffi\libffi-github\include\ffi.h(250) : error C2059: 構文エラー
: ';'
E:\program\src\libffi\libffi-github\include\ffi.h(250) : error C2143: 構文エラー
: ')' が '*' の前にありません。
E:\program\src\libffi\libffi-github\include\ffi.h(250) : error C2143: 構文エラー
: '{' が '*' の前にありません。
E:\program\src\libffi\libffi-github\include\ffi.h(250) : error C2059: 構文エラー
: ')'
E:\program\src\libffi\libffi-github\include\ffi.h(358) : error C2143: 構文エラー
: ')' が '*' の前にありません。
E:\program\src\libffi\libffi-github\include\ffi.h(358) : error C2143: 構文エラー
: '{' が '*' の前にありません。
E:\program\src\libffi\libffi-github\include\ffi.h(359) : error C2146: 構文エラー
: ';' が、識別子 'abi' の前に必要です。
E:\program\src\libffi\libffi-github\include\ffi.h(360) : error C2059: 構文エラー
: '型'
E:\program\src\libffi\libffi-github\include\ffi.h(362) : error C2059: 構文エラー
: ')'
E:\program\src\libffi\libffi-github\include\ffi.h(362) : fatal error C1003: プロ
グラム内のエラーが 100 個を超えました。コンパイルは中断されます。
make[2]: *** [src/debug.lo] Error 1
make[2]: Leaving directory `/cygdrive/e/program/src/libffi/libffi-github'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/cygdrive/e/program/src/libffi/libffi-github'
make: *** [all] Error 2

   include/ffitarget.hのsymlinkが機能していないことによるエラーなので、src/x86/ffitarget.hをinclude/ffitarget.hに上書きコピーする。

8. 再度make。.libsにlibffi.libスタティックリンクライブラリができる。

libffiを使うプロジェクトのリンカーインプットにlibffi.libを指定してやればビルドが通る。libffiの利用例は、testsuite内のコードを参照すればよい。

EnumWindows APIからclosureを呼び出すサンプルコードは以下。

#include <windows.h>
#include <stdio.h>
#include <ffi.h>

static void closure_stub(ffi_cif* cif, void* resp, void** args, void* userdata)
{
	++(*((DWORD*)userdata));

	wchar_t buf[256];
	HWND hwnd = *(HWND*)(args[0]);

	if (::GetWindowTextW(hwnd, buf, 256) != 0 && ::IsWindowVisible(hwnd))
	{
		::wprintf_s(L"HWND: 0x%08x - %s\r\n", DWORD(hwnd), buf);
	}

	*(BOOL*)resp = TRUE;
}

int _tmain(int argc, _TCHAR* argv[])
{
	::setlocale(LC_ALL, "Japanese");

	void* code;
	ffi_closure* pcl = (ffi_closure*)ffi_closure_alloc(sizeof(ffi_closure), &code);

	ffi_type* cl_arg_types[2];
	cl_arg_types[0] = &ffi_type_pointer;
	cl_arg_types[1] = &ffi_type_pointer;

	ffi_cif cif;
	_ASSERTE(ffi_prep_cif(&cif, FFI_STDCALL, 2, &ffi_type_uint32, cl_arg_types) == FFI_OK);

	static DWORD dwInvokeCount = 0;

	_ASSERTE(ffi_prep_closure_loc(pcl, &cif, closure_stub, (void*)&dwInvokeCount, code) == FFI_OK);

	_ASSERTE(::EnumWindows((WNDENUMPROC)code, NULL) != 0);

	::wprintf_s(L"Closure - invoked %d times\r\n", dwInvokeCount);

	ffi_closure_free(pcl);

	return 0;
}

libutpを公開したのはBitTorrent, Inc.で、彼らが配布するBitTorrentクライアントμTorrentのバージョン1.8 betaがµTPを最初に実装した。BitTorrent, Inc.が元々持っていたオリジナルのBitTorrent実装(Mainline)は、Pythonで書かれたソフトウェアとして有名だが、μTorrentはC++で実装されたWindows用ソフトウェアである。μTorrentはスウェーデン人のLudvig Strigeus氏が開発したが、2006年にBitTorrent, Incに買収されている。μTorrentが登場したとき、備えている機能に比して、GUIアプリにしては(パックされている可能性を勘案しても)きわめて小さいバイナリサイズに感心した。プログラマの力量を誇示するかのようなコンパクトで尖ったソフトウェアだったので、後日の買収のニュースには、落ち着くところに落ち着いたなと感じたのを記憶している。

従来のBitTorrentによるファイル転送がTCPを経由して行われていたのに対し、µTPは、UDP上に構築されたプロトコルを用いる。既にDHTやトラッカーのプロトコルにはUDPが利用されていた(ただしμTorrentによる実装はかなり後になった)が、µTPは、トランスポートプロトコルとしてもUDP上に構築した独自プロトコルを利用する。

BitTorrentクライアントが実装したDHT(分散ハッシュテーブル)は、Kademliaというアルゴリズムの実装で、トラッカーに依存しないリソース探索が可能となった。Gnutellaライクな、しかしより構造化された分散キー管理により、トラッカーがダウンしていても目的のリソースを保持するピアのリストを得られる。ネットワークの単一障害点を無くすという建前だが、違法にアップロードされたデータを配布するトラッカーが検挙されつつあった情勢に対抗するものという見方もあった。

今回のµTP実装は、ネットワークの反応が悪くなってきた場合に、自動的に他のトラフィックに道を譲ることで輻輳を防ぐのが目的とされている。オンラインゲームなどのリアルタイム性が重視されるアプリケーションでは一定のレイテンシ以下にping値が収まっていることが要求されるが、TCPのFIFOキューではサイズの大きいP2Pパケットが転送される場合にジッターが発生しやすくサービスの品質に影響を及ぼす。現在のTCPでは、輻輳制御アルゴリズムとして、CUBIC TCP(Linux)、Compound TCP(Windows)が用いられている。µTPは、BitTorrentのアップロード時に起こりやすい輻輳を特に回避するという目的に適う制御アルゴリズムを、UDP上で実装したものということになる。現在、P2Pアプリケーションを対象としてISPによるトラフィックシェイピングが行われているが、これに対しての回答ともいえるだろう。

前置きは以上で、以下コードを見ていく。libutpは、Windows用のdllとして公開されており、VC9用のソリューションが添付されている。utp.defに公開されているCのAPI関数は以下である。

   UTP_Create        @1
   UTP_SetCallbacks  @2
   UTP_SetSockopt    @3
   UTP_Connect       @4
   UTP_IsIncomingUTP @5
   UTP_HandleICMP    @6
   UTP_Write         @7
   UTP_RBDrained     @8
   UTP_CheckTimeouts @9
   UTP_GetPeerName   @10
   UTP_GetDelays     @11
   UTP_Close         @12
   inet_ntop         @13
   inet_pton         @14

このうちinet_ntop/inet_ptonは、Windows VistaからWinsockに実装されているので、古いバージョンのWindows用の実装である。

とりあえずは、µTP接続を生成すると思われるUTP_Createを見てみよう。

// Create a UTP socket
UTPSocket *UTP_Create(SendToProc *send_to_proc, void *send_to_userdata, const struct sockaddr *addr, socklen_t addrlen)
{
	UTPSocket *conn = (UTPSocket*)calloc(1, sizeof(UTPSocket));

	g_current_ms = UTP_GetMilliseconds();

	UTP_SetCallbacks(conn, NULL, NULL);
	conn->our_hist.clear();
	conn->their_hist.clear();
	conn->rto = 3000;
	conn->rtt_var = 800;
	conn->seq_nr = 1;
	conn->ack_nr = 0;
	conn->max_window_user = 255 * PACKET_SIZE;
	conn->addr = PackedSockAddr((const SOCKADDR_STORAGE*)addr, addrlen);
	conn->send_to_proc = send_to_proc;
	conn->send_to_userdata = send_to_userdata;
	conn->ack_time = g_current_ms + 0x70000000;
	conn->last_got_packet = g_current_ms;
	conn->last_sent_packet = g_current_ms;
	conn->last_measured_delay = g_current_ms + 0x70000000;
	conn->last_rwin_decay = int32(g_current_ms) - MAX_WINDOW_DECAY;
	conn->last_send_quota = g_current_ms;
	conn->send_quota = PACKET_SIZE * 100;
	conn->cur_window_packets = 0;
	conn->fast_resend_seq_nr = conn->seq_nr;

	// default to version 1
	UTP_SetSockopt(conn, SO_UTPVERSION, 1);

	// we need to fit one packet in the window
	// when we start the connection
	conn->max_window = conn->get_packet_size();
	conn->state = CS_IDLE;

	conn->outbuf.mask = 15;
	conn->inbuf.mask = 15;

	conn->outbuf.elements = (void**)calloc(16, sizeof(void*));
	conn->inbuf.elements = (void**)calloc(16, sizeof(void*));

	conn->idx = g_utp_sockets.Append(conn);

	LOG_UTPV("0x%08x: UTP_Create", conn);

	return conn;
}

// The uTP socket layer calls this to send UDP packets
typedef void SendToProc(void *userdata, const byte *p, size_t len, const struct sockaddr *to, socklen_t tolen);

SendToProcは、ユーザー定義のパケット送信関数で、UDPなのでsendtoを呼ぶことになるだろう。対象のソケットは、そのユーザー定義関数からアクセスできるところにあらかじめ開いておかなければならない。コネクションレスのUDPなのでソケットは使い回すことになる。対して、ここで作成しているUTPSocketオブジェクトは仮想的なソケットで、TCP風に対象アドレス毎に作成してg_utp_socketsグローバル配列に追加する。

ライブラリで利用する順序上はUTP_Connectを見るべきだが、単にSYNパケットを作成して送信するだけのAPIなので、ここで次に注目すべきはパケット受信時に呼ぶAPIであるUTP_IsIncomingUTPだ。

// Process a UDP packet from the network. This will process a packet for an existing connection,
// or create a new connection and call incoming_proc. Returns true if the packet was processed
// in some way, false if the packet did not appear to be uTP.
bool UTP_IsIncomingUTP(UTPGotIncomingConnection *incoming_proc,
					   SendToProc *send_to_proc, void *send_to_userdata,
					   const byte *buffer, size_t len, const struct sockaddr *to, socklen_t tolen);

ネットワークから受け取ったデータをまずこのAPIに読ませ、µTPのパケットかどうかを判定する。

bool UTP_IsIncomingUTP(UTPGotIncomingConnection *incoming_proc,
					   SendToProc *send_to_proc, void *send_to_userdata,
					   const byte *buffer, size_t len, const struct sockaddr *to, socklen_t tolen)
{
	const PackedSockAddr addr((const SOCKADDR_STORAGE*)to, tolen);

	if (len < sizeof(PacketFormat) && len < sizeof(PacketFormatV1)) {
		LOG_UTPV("recv %s len:%u too small", addrfmt(addr, addrbuf), (uint)len);
		return false;
	}

	const PacketFormat* p = (PacketFormat*)buffer;
	const PacketFormatV1* p1 = (PacketFormatV1*)buffer;

	const byte version = UTP_IsV1(p1);
	const uint32 id = (version == 0) ? p->connid : uint32(p1->connid);

	if (version == 0 && len < sizeof(PacketFormat)) {
		LOG_UTPV("recv %s len:%u version:%u too small", addrfmt(addr, addrbuf), (uint)len, version);
		return false;
	}

生データbufferをPacketFormatにキャストして、パケットの中身を見ていく。

	for (size_t i = 0; i < g_utp_sockets.GetCount(); i++) {
		UTPSocket *conn = g_utp_sockets[i];
		//LOG_UTPV("Examining UTPSocket %s for %s and (seed:%u s:%u r:%u) for %u",
		//		addrfmt(conn->addr, addrbuf), addrfmt(addr, addrbuf2), conn->conn_seed, conn->conn_id_send, conn->conn_id_recv, id);
		if (conn->addr != addr)
			continue;

		if (flags == ST_RESET && (conn->conn_id_send == id || conn->conn_id_recv == id)) {
			LOG_UTPV("0x%08x: recv RST for existing connection", conn);
			if (!conn->userdata || conn->state == CS_FIN_SENT) {
				conn->state = CS_DESTROY;
			} else {
				conn->state = CS_RESET;
			}
			if (conn->userdata) {
				conn->func.on_overhead(conn->userdata, false, len + conn->get_udp_overhead(),
									   close_overhead);
				const int err = conn->state == CS_SYN_SENT ?
					ECONNREFUSED :
					ECONNRESET;
				conn->func.on_error(conn->userdata, err);
			}
			return true;
		} else if (flags != ST_SYN && conn->conn_id_recv == id) {
			LOG_UTPV("0x%08x: recv processing", conn);
			const size_t read = UTP_ProcessIncoming(conn, buffer, len);
			if (conn->userdata) {
				conn->func.on_overhead(conn->userdata, false,
					(len - read) + conn->get_udp_overhead(),
					header_overhead);
			}
			return true;
		}
	}

UTPSocketの接続先を比較して、受信パケットが既に管理中のUTPSocketに属する物であれば、ここで処理される。SYNパケット(ST_SYN)でない場合は、送信データの内容を受け取ったことになるので、UTP_ProcessIncoming関数で処理する。その後RSTパケットの処理が続いてから、最後はSYNパケットを受け取って、ピアからの接続要求を処理する。

	if (incoming_proc) {
		LOG_UTPV("Incoming connection from %s uTP version:%u", addrfmt(addr, addrbuf), version);

		// Create a new UTP socket to handle this new connection
		UTPSocket *conn = UTP_Create(send_to_proc, send_to_userdata, to, tolen);
		// Need to track this value to be able to detect duplicate CONNECTs
		conn->conn_seed = id;
		// This is value that identifies this connection for them.
		conn->conn_id_send = id;
		// This is value that identifies this connection for us.
		conn->conn_id_recv = id+1;
		conn->ack_nr = seq_nr;
		conn->seq_nr = UTP_Random();
		conn->fast_resend_seq_nr = conn->seq_nr;

		UTP_SetSockopt(conn, SO_UTPVERSION, version);
		conn->state = CS_CONNECTED;

		const size_t read = UTP_ProcessIncoming(conn, buffer, len, true);

		LOG_UTPV("0x%08x: recv send connect ACK", conn);
		conn->send_ack(true);

		incoming_proc(send_to_userdata, conn);

		// we report overhead after incoming_proc, because the callbacks are setup now
		if (conn->userdata) {
			// SYN
			conn->func.on_overhead(conn->userdata, false, (len - read) + conn->get_udp_overhead(),
								   header_overhead);
			// SYNACK
			conn->func.on_overhead(conn->userdata, true, conn->get_overhead(),
								   ack_overhead);
		}
	}

incoming_procはアプリケーション定義コールバックで、ACK送信後に呼ばれる。

それでは、UTP_ProcessIncoming関数を見てみよう。

// Process an incoming packet
// syn is true if this is the first packet received. It will cut off parsing
// as soon as the header is done
size_t UTP_ProcessIncoming(UTPSocket *conn, const byte *packet, size_t len, bool syn = false)
{
	UTP_RegisterRecvPacket(conn, len);

	g_current_ms = UTP_GetMilliseconds();

	conn->update_send_quota();

	const PacketFormat *pf = (PacketFormat*)packet;
	const PacketFormatV1 *pf1 = (PacketFormatV1*)packet;
	const byte *packet_end = packet + len;

	// snip

	// mark receipt time
	uint64 time = UTP_GetMicroseconds();

	// snip

	uint64 p;

	if (conn->version == 0) {
		p = uint64(pf->tv_sec) * 1000000 + pf->tv_usec;
	} else {
		p = pf1->tv_usec;
	}

	conn->last_measured_delay = g_current_ms;

	// get delay in both directions
	// record the delay to report back
	const uint32 their_delay = (uint32)(p == 0 ? 0 : time - p);
	conn->reply_micro = their_delay;
	uint32 prev_delay_base = conn->their_hist.delay_base;
	if (their_delay != 0) conn->their_hist.add_sample(their_delay);

	// if their new delay base is less than their previous one
	// we should shift our delay base in the other direction in order
	// to take the clock skew into account
	if (prev_delay_base != 0 &&
		wrapping_compare_less(conn->their_hist.delay_base, prev_delay_base)) {
		// never adjust more than 10 milliseconds
		if (prev_delay_base - conn->their_hist.delay_base <= 10000) {
			conn->our_hist.shift(prev_delay_base - conn->their_hist.delay_base);
		}
	}

	const uint32 actual_delay = conn->version==0
		?(pf->reply_micro==INT_MAX?0:(uint)pf->reply_micro)
		:(uint)pf1->reply_micro;

	assert(conn->our_hist.get_value() >= 0);
	// if the actual delay is 0, it means the other end
	// hasn't received a sample from us yet, and doesn't
	// know what it is. We can't update out history unless
	// we have a true measured sample
	prev_delay_base = conn->our_hist.delay_base;
	if (actual_delay != 0) conn->our_hist.add_sample(actual_delay);
	assert(conn->our_hist.get_value() >= 0);

	// if our new delay base is less than our previous one
	// we should shift the other end's delay base in the other
	// direction in order to take the clock skew into account
	// This is commented out because it creates bad interactions
	// with our adjustment in the other direction. We don't really
	// need our estimates of the other peer to be very accurate
	// anyway. The problem with shifting here is that we're more
	// likely shift it back later because of a low latency. This
	// second shift back would cause us to shift our delay base
	// which then get's into a death spiral of shifting delay bases
/*	if (prev_delay_base != 0 &&
		wrapping_compare_less(conn->our_hist.delay_base, prev_delay_base)) {
		// never adjust more than 10 milliseconds
		if (prev_delay_base - conn->our_hist.delay_base <= 10000) {
			conn->their_hist.Shift(prev_delay_base - conn->our_hist.delay_base);
		}
	}
*/
	// only apply the congestion controller on acks
	// if we don't have a delay measurement, there's
	// no point in invoking the congestion control
	if (actual_delay != 0 && acked_bytes >= 1)
		conn->apply_ledbat_ccontrol(acked_bytes, actual_delay, min_rtt);

UTP_GetMicrosecondsは、QueryPerformanceCounterを用いて(monotonicになるように修正した上で)マイクロ秒単位の時間を取得する。それと、パケットに記録されている時間との差分を取っている。

ここでわかるのは、アップロードされた送信パケットが実際に着信するまでにかかった時間(their_delay)をreply_microとして保存し、返信して、それを受け取った側で遅延(actual_delay)として解釈しているということだ。つまり、パケットが行って帰ってくるまでのラウンドトリップタイム(RTT)ではなく、アップロード時の遅延を計測して輻輳を検出しようとしている。この後、apply_ledbat_ccontrol関数によって、場合によってはウィンドウサイズを変化させて他のTCP接続を優先することになる。

void UTPSocket::apply_ledbat_ccontrol(size_t bytes_acked, uint32 actual_delay, int64 min_rtt)
{
	// the delay can never be greater than the rtt. The min_rtt
	// variable is the RTT in microseconds

	assert(min_rtt >= 0);
	int32 our_delay = min<uint32>(our_hist.get_value(), uint32(min_rtt));
	assert(our_delay != INT_MAX);
	assert(our_delay >= 0);
	assert(our_hist.get_value() >= 0);

	SOCKADDR_STORAGE sa = addr.get_sockaddr_storage();
	UTP_DelaySample((sockaddr*)&sa, our_delay / 1000);

	// This test the connection under heavy load from foreground
	// traffic. Pretend that our delays are very high to force the
	// connection to use sub-packet size window sizes
	//our_delay *= 4;

	// target is microseconds
	int target = CCONTROL_TARGET;
	if (target <= 0) target = 100000;

	double off_target = target - our_delay;

	// this is the same as:
	//
	//    (min(off_target, target) / target) * (bytes_acked / max_window) * MAX_CWND_INCREASE_BYTES_PER_RTT
	//
	// so, it's scaling the max increase by the fraction of the window this ack represents, and the fraction
	// of the target delay the current delay represents.
	// The min() around off_target protects against crazy values of our_delay, which may happen when th
	// timestamps wraps, or by just having a malicious peer sending garbage. This caps the increase
	// of the window size to MAX_CWND_INCREASE_BYTES_PER_RTT per rtt.
	// as for large negative numbers, this direction is already capped at the min packet size further down
	// the min around the bytes_acked protects against the case where the window size was recently
	// shrunk and the number of acked bytes exceeds that. This is considered no more than one full
	// window, in order to keep the gain within sane boundries.

	assert(bytes_acked > 0);
	double window_factor = (double)min(bytes_acked, max_window) / (double)max(max_window, bytes_acked);
	double delay_factor = off_target / target;
	double scaled_gain = MAX_CWND_INCREASE_BYTES_PER_RTT * window_factor * delay_factor;

	// since MAX_CWND_INCREASE_BYTES_PER_RTT is a cap on how much the window size (max_window)
	// may increase per RTT, we may not increase the window size more than that proportional
	// to the number of bytes that were acked, so that once one window has been acked (one rtt)
	// the increase limit is not exceeded
	// the +1. is to allow for floating point imprecision
	assert(scaled_gain <= 1. + MAX_CWND_INCREASE_BYTES_PER_RTT * (int)min(bytes_acked, max_window) / (double)max(max_window, bytes_acked));

	if (scaled_gain > 0 && g_current_ms - last_maxed_out_window > 300) {
		// if it was more than 300 milliseconds since we tried to send a packet
		// and stopped because we hit the max window, we're most likely rate
		// limited (which prevents us from ever hitting the window size)
		// if this is the case, we cannot let the max_window grow indefinitely
		scaled_gain = 0;
	}

	if (scaled_gain + max_window < MIN_WINDOW_SIZE) {
		max_window = MIN_WINDOW_SIZE;
	} else {
		max_window = (size_t)(max_window + scaled_gain);
	}

	// make sure that the congestion window is below max
	// make sure that we don't shrink our window too small
	max_window = clamp<size_t>(max_window, MIN_WINDOW_SIZE, opt_sndbuf);

CCONTROL_TARGETは今のところ100 * 1000µs = 100msで、100msを下回っていれば目標のレイテンシが達成できているということになる。ターゲットから外れている数値(off_target)に応じてscaled_gainを算出し、100msよりレイテンシが低ければウィンドウサイズ(max_window)を大きくし、100msを超えていたら輻輳とみなしてウィンドウサイズを小さくし、別のアプリケーションに道を譲るという輻輳制御が行われる。

この後、UTP_ProcessIncomingでは、Selective ACKという処理でパケットロスを判定する。

	// count bytes acked by EACK
	if (selack_ptr != NULL) {
		acked_bytes += conn->selective_ack_bytes((pk_ack_nr + 2) & ACK_NR_MASK,
												 selack_ptr, selack_ptr[-1], min_rtt);
	}

void UTPSocket::selective_ack(uint base, const byte *mask, byte len)
{
	// snip

	bool back_off = false;
	int i = 0;
	while (nr > 0) {
		uint v = resends[--nr];
		// don't consider the tail of 0:es to be lost packets
		// only unacked packets with acked packets after should
		// be considered lost
		OutgoingPacket *pkt = (OutgoingPacket*)outbuf.get(v);

		// this may be an old (re-ordered) packet, and some of the
		// packets in here may have been acked already. In which
		// case they will not be in the send queue anymore
		if (!pkt) continue;

		// used in parse_log.py
		LOG_UTP("0x%08x: Packet %u lost. Resending", this, v);

		// On Loss
		back_off = true;
#ifdef _DEBUG
		++_stats._rexmit;
#endif
		send_packet(pkt);
		fast_resend_seq_nr = v + 1;

		// Re-send max 4 packets.
		if (++i >= 4) break;
	}

	if (back_off)
		maybe_decay_win();

	duplicate_ack = count;
}

同じACKを3回受け取った場合、輻輳が激しくなってパケットロスが起きたとみなし、パケット再送を促すとともに、maybe_decay_winを呼んでウィンドウサイズを縮小する。ここはTCP Reno同様である。

µTPの基本的な動作は、以上である。一見する限り、これでμTorrentを起動していてもWebブラウザを含む他のネットワークアプリの動作が重くならなくなるのであれば、万歳といったところだ。ところが、torrentコミュニティの中では、事実上μTorrentが(µTPをサポートする)μTorrentのみをピアとして優先するようになり他のクライアントが差別されかねないことや、µTP適用で絶対的転送速度が下がる可能性があることを危惧して、µTPに対しての批判や慎重論も根強いようである。とはいえ、μTorrentが現在非常に大きなシェアを占めていることは事実であり、µTPを実装するクライアントが増加するのも時間の問題だろう。BitCometやXunleiといった中国で人気のあるクライアントが追随すれば、さらに趨勢は決定的となる。

my ( $x, $y ) = $self->invoke(
	+{
		METHOD => 'foo',
		PARAM => 'bar',
	},
	''
);

In this Perl snippet, I had no idea what “+{}” stands for. It looks like some kind of hash, but not sure. Googling it didn’t bring good results since Google doesn’t recognize a string made only of non-alphabetical characters such as braces and math operators.

To figure out its meaning I wasted so much time by trying many different words in Google. Anyway here’s the answer:

or to force an anon hash constructor use +{:

   @hashes = map +{ lc($_) => 1 }, @array # EXPR, so needs comma at end

to get a list of anonymous hashes each with only one entry apiece.

It’s embedded in perlfunc and I couldn’t find any other references in the official documents.

I had a hard time with Ruby too when the last argument for a method has an ampersand (&) prepended. In the Japanese version of the Ruby manual, it’s obscurely explained in a single line. It’s very hard to find since there’s no word for an ampersand in Japanese. It has no English version but The Ruby Programming Wikibooks has a related part which is a lot better with examples.

The ampersand (&)

The ampersand operator can be used to explicitly convert between blocks and Procs in a couple of cases. It is worthy to understand how these work.

Remember how I said that although an attached block is converted to a Proc under the hood, it is not accessible as a Proc from inside the method ? Well, if an ampersand is prepended to the last argument in the argument list of a method, the block attached to this method is converted to a Proc object and gets assigned to that last argument:

def contrived(a, &f)
     # the block can be accessed through f
     f.call(a)

     # but yield also works !
     yield(a)
 end

 # this works
 contrived(25) {|x| puts x}

 # this raises ArgumentError, because &f
 # isn't really an argument - it's only there
 # to convert a block
 contrived(25, lambda {|x| puts x})

Regarding manuals, MSDN is still the best place. Don’t know what “=>” means in C#? OK search it in the C# operators. It’s the lambda operator introduced in C# 3.0. Since I always code with a language specification on my side when it’s not C++, the quality of reference documents can be directly reflected in productivity.

The core value of DI is basically represented in these 2 points:

1. Testability. DI makes testing easy by enabling loosely coupled components that are easily replaced with mock objects.
2. Dependency control. When you deploy a DI framework instead of using the Factory Method pattern, dependency can be managed outside of components.

The first point is rather obvious. To understand the second point, I recommend you to browse the Google Giuce lightweight Java DI framework for its video presentation and documents. It illustrates the necessity of such a framework for Java in a straightforward way. Particularly, Giuce appears to be a neat implementation of DI where you don’t need to manage XML configuration files unlike other frameworks. Just like inner DSL, dependency is handled in type-safe Java code even though it ditches type-safe factories scattered in code.

But, as Ruby and other dynamic languages gets more attention, the relative mind share of DI seems to get smaller. In Ruby, you can swap methods of instances dynamically at the side of a test class. The dynamic nature of Ruby can enable whole other tricks dependent on it such as ActiveRecord.

So what about DI? Is it just a glorified abstract factory? Unfortunately, there still have to be environments where DI makes things a lot easier. Not just Java, but other static language, such as C++. Since my programming history is MS-Windows-centric, my interest toward DI is its applicability for Windows app development. DI is a lot discussed in the context of Java/.NET enterprise development, but its necessity would be even higher in C++ development on Windows as long as other requirements such as performance permit.

If you are a Windows programmer, IoC can’t be a novel concept since without it no Windows GUI application can be built. Plugging in your implementation code into some framework is not an alien concept for us. As for DI, its merit of testability is a big plus for a project that includes many C++ components and consumes mind-bogglingly long time to rebuild.

But DI discussion seems thin around here. Why? It seems existing implementations in Java often rely on reflection which is not available in C++. For example, Giuce uses @inject annotation to tell injection points. It may be just for its AOP features, but lacking reflection makes it a lot harder to implement. Using exotic macros and templates can change the situation, but I guess not much. Another issue is, as I mentioned already, it’s a form of late binding hence performance hit is expected. If you design it not to get hit hard, it will not be loosely coupled any more. At this point, I almost gave up the idea of DI for Windows C++.

Instead, my interest shifted to finding the next best thing available which can help us to test binary components without hassle. So I searched – and found a solution. It’s called registration-free COM or Reg-Free COM.

OK don’t stone me :) It’s a very nice feature or a hidden gem in Windows. It’s only available on Windows XP and later, but it won’t be a problem. The basic idea behind COM (Component Object Model) is a binary interface for reusable components. A part of its concept was later adopted by XPCOM for Mozilla Firefox.

One issue that nags developers and users regarding the use of COM components is it requires Registry entry to resolve an interface query. GUIDs of COM components have to be registered with regsvr32.exe in the HKEY_CLASSES_ROOT (HKCR) Registry key. It makes deployment of COM components really cumbersome even though COM itself is a really reasonable technology. Uninstalling them can be a PITA too.

Enter Reg-Free COM, now Registry entry is not necessary to use a COM component as long as XML manifests are provided to load correct components. In normal COM, the ClassFactory and related platform facility searches Registry entry when a specific CLSID or IID is requested in CoCreateInstance or QueryInterface, whereas in Reg-Free COM dependency resolution is done at application startup by parsing manifests. There are 2 kinds of manifests: application manifest and assembly manifest. The former describes on what components an application depends. The latter describes assembly’s identity such as a dll file name and CLSID.

A typical application manifest is as follows (lifted from the sample at MSDN)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
            type = "win32"
            name = "client"
            version = "1.0.0.0" />
<dependency>
            <dependentAssembly>
                        <assemblyIdentity
                                    type="win32"
                                    name="SideBySide.X"
                                    version="1.0.0.0" />
            </dependentAssembly>
</dependency>
</assembly>

It shows it depends on an assembly with the name “SideBySide.X”. The dll loader tries to find a file with the name “SideBySide.X.manifest” when reading this application manifest. In SideBySide.X.manifest, its correspondent dll is described.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

<assemblyIdentity
	type="win32"
	name="SideBySide.X"
	version="1.0.0.0" />

<file name = "SideBySide.dll">

<comClass
    clsid="{4B72FC46-C543-4101-80DB-7777848D1357}"
    threadingModel = "Apartment" />

<typelib tlbid="{E6A9CD40-8559-4E17-A0D9-C68B038B4FA0}"
       version="1.0" helpdir=""/>

</file>

<comInterfaceExternalProxyStub
    name="ISideBySideClass"
    iid="{CBA85B94-9C11-43aa-84F6-30B90145FD3E}"
    proxyStubClsid32="{00020424-0000-0000-C000-000000000046}"
    baseInterface="{00000000-0000-0000-C000-000000000046}"
    tlbid = "{E6A9CD40-8559-4E17-A0D9-C68B038B4FA0}" />

</assembly>

A comInterfaceExternalProxyStub node is necessary when a component is called in a different kind of a thread apartment from that of the component.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
            type = "win32"
            name = "client"
            version = "1.0.0.0" />
<dependency>
            <dependentAssembly>
                        <assemblyIdentity
                                    type="win32"
                                    name="SideBySide.X"
                                    version="1.0.0.0" />
            </dependentAssembly>
</dependency>
</assembly>

これが、かつてOracleが提唱したネットワークコンピュータを越えていくものとなるかどうかは、実際のプロダクトの出来を見なければ、占うにはまだ早すぎるといわざるをえない。それでも、Google Chromeに続きChrome OSによって、Googleが考えるところの理想のクライアント環境を実現しようとする動きは、きわめて自然であるし、一貫性があるといえる。しかし、この一貫性は、単にGoogle内部で完結しているものではなく、歴史的な流れの中のある一点で、たまたまGoogleという企業が、マイルストーンとして一般に認知される発表を行うことを可能とするリソースや動機を有していた、という見方もできよう。

この仮想的な歴史をめぐる可能世界で、Chrome OSの前駆者として、またもう一つの可能性として念頭にあるのは、Microsoftの活動だ。今年の2月に発表されたGazelleは、プリンシパルベースのセキュリティという概念を主軸に置いて、Google Chromeより徹底したセキュリティアーキテクチャのWebブラウザを、OSをも巻き込んだ形で実装してしまおうという試みである。このアプローチは、Google Chrome実装の経緯と、興味深い鏡像関係を成している。Google Chromeの実装者らは、Windows上でセキュリティサンドボックスを実現するために、Windows XP SP2の実装に深く依存せざるを得なかった。市場を独占するOSのAPIや実装を管理できるというリソースを持ち合わせるMicrosoftにとっては、そのあたりの苦労は、技術的なものではなく、単に手続き的なものでしかない。そして、Gazelleが理論として存在したとしても、それが実際の製品に生かされるかどうかは、別の次元の話である。

Gazelleという試みと別の次元で並行して走る現実世界でのMicrosoftの問題は、法的な懸念である。1997年のInternet Explorer 4で、MicrosoftはOSのシェルとWebブラウザの統合を図った。その余波が、WebブラウザなどのコンポーネントをOSに同梱する際に紛糾するというヨーロッパでの今日的状況にまで及んでいる。この、法的な懸念をかわしつつ、MicrosoftがGazelleを実現しようとするならば、必要な機能のほとんどはOS側に盛り込んで、それを自社のWebブラウザからだけではなく他社からも利用できるようにすることになるだろう。Webブラウザというアプリケーションに固有の部分は、3層アーキテクチャでいえば、データの表示を司るいわゆるプレゼンテーション層や、Webブラウザ固有の操作に限定されたビジネスロジック層に限ったものとなり、データのやり取りを管理するデータ層は、OSが引き取ることになる。

ここで、Webブラウザの話に戻ると、Google Chromeの構成は、すでにそのような階層を前提としている。データのやり取りや管理を行うカーネルと、データの表示を行うレンダラーの分離は、Gazelle的なOSにおけるOSとアプリケーションの関係にそのままあてはまる。であれば、GoogleもまたOSに向かうのは当然の流れだろう。その意味で、Google Chromeとは、Windows等のOSの中に、Googleの植民地としての仮想OSを構築するという試みであったといえる。そして、仮想OSをOSに変えるには、ハードウェアとの仲立ちを行ってくれる層(たとえばLinuxカーネル)があればよい。

Webブラウザを仮想OSとしてとらえ、各々の機能を別プロセスに分けサンドボックス化してセキュリティを担保するという構成自体は、Google Chromeが初めてではない。2008年3月に発表されているOpus Palladianumは、まさにそのような実験だった。そこでの課題は、パフォーマンスである。データの流れに対して要所要所で監査が行われるため、そのためのレイテンシ増大が問題となっていた。これに対し、Google Chromeの場合は、機能分割の粒度を下げたり、各々の部品の最適化を進めることで、現実解を導いている。

いずれにせよ、ネットワークリソースのサンドボックス化、仮想マシン化、そしてクラウド化というトレンドは、最早後戻りのないポイントにまで進展してきている。このリアリティ(Red Pill)を受け入れ、積極的に生かすことができるか、もしくは幸福な幻想(Blue Pill)のもとに留まるか – 今後数年で、さまざまな選択と、その結果を目にすることになるのは間違いない。

更新を再開しようかと思ったのだが、まだネタがないので仕方なくblog風に先日撮った写真(芝公園にて、2009年4月3日)で茶を濁す。

昨年も書いているように、サイト自体をCMSかblogツールにいい加減移行したいと本当は思っていて、そのくせ時間がないので踏み切れないでいる。

VS2008はやっと自分のPCにインストールしたところで、昨年書いた課題に取りかかる以前の段階で1年以上足踏みしてしまっている。その間に生活環境が変化したため、以前描いていた計画も、実装に取りかかる遙か以前の段階で既に再検討を余儀なくされている。具体的には、DICEに関して、ある部分のみC++/CLIを用いて.NET化することを考えていた。それというのも、ネイティブコードもそろそろ潮時かと考えて、C++を利用する部分を徐々に縮小させることを意図していたからであった。現在もその方針自体は誤りではなかったと考えているが、今それを為すべきか、そのための時間があるかということを熟慮すると、同じ時間を使うにしても他にやらなければならないことがあるのではないかというのが今回至った結論である。

また、去年計画・調査だけ行って結局頓挫したものとして、どのみち日の目を見ないだろうから忘れないうちに書いてしまうと、RTMPをDICEに実装することを考えていた。それというのも、抽象サーバーフレームワークであるDICEのプロトコル実装の試金石として商業的に意味のありそうなプロトコルを是非実装しておきたかったのと、Flashとの親和性を高めておきたかったという事情がある。サーバー用のソフトウェアスタック(と.NETで作った簡易クライアント)しかコントロールできない私にとって、Flash + JavaScriptはクライアントアプリ作成のためのRAD環境たり得た。ところが状況は変わり、C++の非常に有望なクライアント用ソフトウェアスタックが自由なライセンスの元で利用できることになり、今はそれをどう活かすかについて思案している。勘の良い諸兄ならそれが何かもうお分かりだろう。

本記事の環境はVS2005(VC8)である。PHPはPHP 5.25を用いた。PHP組み込みに関する公式の資料はPHPマニュアル第7章に存在する。46節の”Zend API: Hacking the Core of PHP“に変数の操作に関して記述がある。ところが、現時点のPHPマニュアルには、組み込みの際の初期化についてすら解説がない。PHPソースコードを展開した際にphp-5.2.5\sapi\embedフォルダに見つかるphp_embed.hならびにphp_embed.cを参照すると、初期化/終了マクロがあり、初期化の際にsapi_startup関数を呼んでいるのが分かる。これはmain\SAPI.hならびにSAPI.cに定義されており、引数となる構造体_sapi_module_structにコールバックを登録してPHPのSAPI(Server API)を初期化している。そのコールバックの中でも、php_embed_ub_writeがprintなどの出力を受ける関数で、php_embed.c内ではphp_embed_ub_writeを経由してphp_embed_single_writeに至り、標準出力へ出力されている。つまりそこをオーバライドしてやればユーザ側でスクリプトの出力を受け取れるのであり、基本的にはRuby組み込みで使われる方法と同一だが、PHPはSAPIフレームワークの中でインターフェイスをユーザ側に提供している点が異なる。

ユーザコードの概要が掴めたところで、次にPHP組み込みに必要な環境を作らなければならない。先に書いておくが、ここにまず問題がある。PHPのソースコードをダウンロードしてローカルに展開した後に、マニュアルのWindows上でのビルド方法に従ってビルドを行う。win32build.zipと bindlib_w32.zipもビルドに必要なGNUツールなどを含んでいるので所定の場所へ展開しておく必要がある。ビルドには、Visual C++ツールのコマンドプロンプトを使用する。今回は組み込みを行うので、WSHを経由してconfigure.jsを呼び出しmakeの設定を行う際に、--enable-embedを引数に加えることになる。

ところが、そのままビルドを始めると、エラーが出てストップしてしまう。エラーコードを見ると、libxmlに問題が起こっているらしい。そこで libxml2をダウンロードしてパスを通すも、やはりビルドが通らない。今度はどうやらiconvが必要なようで、最新版libiconvをダウンロー ドしてみると、なんと以前は入っていたVC++サポートがどういうわけか削除されていた。mingwでビルドせよとあるので試してみたがどうも上手くいかない。しかも、ダウンロード元がGNUだったことを思い出し、これはライセンス的にまずいのではないかと後から気付いた。iconvに由来するコードが PHPのスタティックライブラリに含まれているとすれば、PHP組み込みを行った時点でLGPLに汚染され、ユーザプログラムの配布に支障が出てしまう。 そこで、仕方なく--without-libxmlをconfigure.jsのオプションに加え、XMLサポートを諦めた。調べてみると、iconv自体はPHP 5からPHP本体に組み込まれており、php-5.2.5\ext\iconvを見る限りクリーンルーム実装がなされている。このあたりlibxmlもどうにかできないものかと思うがここでは深く追及しない。

libxml/iconvの問題以外にもビルドプロセスには問題があり、ZLIBの関数も使用できないので--disable-zlibで無効にする。これでようやくphp-5.2.5\Release_TSないしphp-5.2.5\Debug_TSに、アプリケーションにリンクするスタティックライブラリ(php5embed.lib)と実行時に必要なdllファイル(php5ts.dll)が出来上がる。次にVC++の設定として、メニューの「ツール | オプション」からVC++のディレクトリにlibファイルの場所を追加し、さらにプロジェクト設定内のincludeファイルのフォルダにphp-5.2.5\、php-5.2.5\sapi\embed、php-5.2.5\Zend、php-5.2.5\TSRMを加える。さらに、PHP_WIN32、ZEND_WIN32各シンボルの定義が必要となる。また、実際には、VC8からtime_tが64ビットになっているため_USE_32BIT_TIME_Tも定義しなければクライアントコードのビルドは成功しない。以上でどうにか環境が整ったので、以下のコードがPHP組み込みのサンプルとしてビルド、実行できる。

#include <stdio.h>
#include <tchar.h>

#include <iostream>
#include <string>
#include <cstdio>

#include <php.h>
#include <php_embed.h>

using namespace std;

static int php_ub_write(const char* str, unsigned int str_length TSRMLS_DC)
{
	string s(str, str_length);

	cout << s;

	return str_length;
}

static void php_log_message(char* message)
{
	cerr << "php_log_message: " << message  << endl;
}

static void php_sapi_error(int type, const char* fmt, ...)
{
	va_list va;
	va_start(va, fmt);
	printf("php_sapi_error: ");
	vprintf(fmt, va);
	va_end(va);
}

int _tmain(int argc, _TCHAR* argv[])
{
	php_embed_module.ub_write = php_ub_write;
	php_embed_module.log_message = php_log_message;
	php_embed_module.sapi_error = php_sapi_error;

	char* argv2[] = {""};

	PHP_EMBED_START_BLOCK(0, argv2);

	zval* v = NULL;

	MAKE_STD_ZVAL(v);
	ZVAL_STRING(v, "Hello", 1);
	ZEND_SET_SYMBOL(&amp;EG(symbol_table), "hello", v);

	zend_eval_string("print \"$hello \";$hello = \"World\";", NULL, "" TSRMLS_CC);

	if (v->type == IS_STRING)
	{
		cout << string(v->value.str.val, v->value.str.len) << endl;
	}

	PHP_EMBED_END_BLOCK();

    return 0;
}

PHP関係のヘッダは他の標準ヘッダの後に置かなければエラーが出るようだ。コードの内容は、上述のように出力関数をオーバライドし、さらに$helloという名称の変数を作成して操作し最終的にHello Worldを表示するというたわいのないものである。PHP_EMBED_START_BLOCK、PHP_EMBED_END_BLOCKが初期化、終了のマクロで、内部でzend_first_try/zend_catchのブロックを作っているので変数のスコープに注意しなければならない。前回のPerl組み込みの場合だとPerlでの例外をラップする仕組みを自前で作る必要があったのに対し、PHPの方はZendが面倒を見てくれる点は有り難い。

とはいえ、このようにしてビルドした物だとPHP 5の特徴的機能であるところのXMLがおそらく使用できない事はかなりの損失である。そこで、次に考えられる方法として、PHPの配布バイナリ内のライブラリを利用するという道がある。PHPの配布バイナリには、(一体どうやってビルドしたのかは謎だが)php5embed.libとphp5ts.dllが含まれているのである。Dependency Walkerでphp5ts.dllを覗いてみてもCライブラリがスタティックリンクされているので一見使い勝手が良いように見える。ところが、落とし穴があり、デバッグ版だとVC++のdllが異なってくるので、これを使った場合正常にデバッグが出来なくなってしまう。そこで、開発の際には自分でビルドしたlibファイルを使い、リリース版は配布バイナリの方を利用することになる。

しかし、拍子抜けではあるが、最終的にDICEでは上述のようなストレートな組み込み方法は採らなかった。というのも、不透明なライセンスの問題に加え、上述のやり方ではPHPスクリプトやASP(Active Server Pages)の最も有用な機能である、コードブロックのHTML埋め込みが出来ないのである(出来る方法があるのかも知れないがそれは本稿の範囲を超える)。これではこちらで配布するWebサーバに組み込んで利用するという本来の目的にそぐわない。そこで、結局DICEの方にISAPIエクステンションのサポートを入れ、ISAPIを経由してPHPをロードする形に落ち着いた。PHPはSAPIという組み込みインタフェイスを用意しており、PHPの配布バイナリにはISAPIエクステンションのdllが含まれている。この組み込み方法であればライセンス問題は完全にクリーンであり、PHP設定ファイルの読み込みなどの付随的処理もPHP側で全て自動的に行ってくれる。PHPはかなり素直なISAPIアクセスしか行わないので、別にwebサーバへの組み込み用途ではなくても、Windows上で ライセンスが気になる場合等はPHPそのものの組み込みの代わりにISAPIを経由してコントロールするのも一つの有力な選択肢ではないかと思う。他方で、配布を目的とせずサーバ側でのみ利用する場合はライセンスに関する問題はもちろん発生しないため、最初に取り上げた組み込み手順もそれはそれで有用となる局面もあるだろう。