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)
 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!

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?

Thank you,
Rogiel Sulzbach

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Reply via email to