[swift-corelibs-dev] Issue understanding libdispatch runloop poking

[Pierre Habouzit]

> On Oct 12, 2017, at 7:48 AM, Rogiel Sulzbach <rogiel at rogiel.com> wrote:
> 
> I am trying to get libdispatch working on FreeBSD but I am hitting a wall: I cannot get my head around how the runloop implementation dispatches a event to the kqueue once a new job is submitted. So far I was able to get the library to fully compile but most tests are timing out due to a issue getting the kqueue event handler to awake when the poke method is called.
> Looking at the Linux implementation (https://github.com/apple/swift-corelibs-libdispatch/blob/master/src/queue.c#L6119) <https://github.com/apple/swift-corelibs-libdispatch/blob/master/src/queue.c#L6119)> it appears to be creating a new eventfd descriptor and calls eventfd_write on the poke method. A eventfd_read call is only made in the event_epoll.c implementation file BUT I am unable to find where the specific fd (created in queue.c) is forwarded to the epool handler. In other words, how is the event queue implementation informed of that file descriptor?
> On the Darwin side of things, it appears to use a mix of kqueue (on the event handling side) and mach ports (on the signaling side), but i still cannot understand how the event_kevent.c implementation becomes aware of that port allocated on queue.c.
> In order do get dispatch working on FreeBSD I need to be able to understand the flow that happens between _dispatch_runloop_queue_class_poke and a event getting fired in the kqueue implementation (which I believe should be happening in _dispatch_kq_poll).
> 
> Pierre Habouzit replied to me on the bug tracker:
> The equivalent of the eventfd on kevent systems is to use an EVFILT_USER. It is very likely that the current implementation using kevent is badly broken on FreeBSD it has never run for a very long time. I have no access to FreeBSD at this time to help though but I can help with questions on the list.
> Indeed, the entire library needed changes in 39 files to get compiling, let alone working! But I am getting there!

39 seems a bit excessive so I'd encourage you when you submit this awesome porting effort to try to check in individual "porting fixes" in separate branches.

You should also try to get it working at the C level before you try to integrate with Swift, runloop queues are not required to get the basic library working

> 
> If i am understanding it correctly, I must send a EVFILT_USER and upon receiving that event I get the corresponding unote and call dux_merge_evt. Right?

Hmm actually when answering on Jira I had missed that you were talking about runllops. However, the equivalent of eventfd on kevent will be EVFILT_USER.

You will need to first work on the implementation of CFRunloop itself to understand how it "blocks". It will likely park in kevent() with a kqueue fd.

The CFRunloop in question will prepare an EVFILT USER that represents "availability" of dispatch items to drain in the runloop queue. the difficulty is that unlike epoll of portsets on the Mac, the runloop queue has to know your kqueue fd. So you need to devise a way to pass it down.

Once you have done that _dispatch_runloop_queue_class_poke() on FreeBSD will issue a NOTE_TRIGGER of the EVFILT_USER which will break the CFRunloo parked in kqueue() out, and this will recognize the EVFILT_USER as being the hint that you need to drain it.

I would suggest that on FreeBSD you add a _dispatch_runloop_queue_set_kqueue() which you will store where the fd/mach port is stored on other platforms.

-Pierre

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20171012/32aca033/attachment.html>