> On Oct 12, 2017, at 4:52 PM, Pierre Habouzit via swift-corelibs-dev > <swift-corelibs-dev@swift.org> wrote: > >> On Oct 12, 2017, at 7:48 AM, Rogiel Sulzbach <rog...@rogiel.com >> <mailto:rog...@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.
it also means that you likely need to export some function shared between Swift & Dispatch to "recognize" the knote in question, you'll need to pick an ident and a udata field. You probably want to have defines in <dispatch/private.h> when on FreeBSD for this purpose, since both dispatch & CF/Swift will need to know how to form the knote in question. -Pierre
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
