[swift-corelibs-dev] libdispatch roadmap and api addition proposal

[Pierre Habouzit]

> On Dec 8, 2015, at 6:11 AM, Joakim Hassila via swift-corelibs-dev <swift-corelibs-dev at swift.org> wrote:
> 
> Hi Daniel,
> 
> 
>> On 7 dec. 2015, at 23:11, Daniel A. Steffen <das at apple.com> wrote:
>> 
>> FWIW I’ve updated the macosforge svn repo trunk to match with github swift-corelibs-libdispatch trunk (sans the PRs, excecpt for my buildsystem one), but going forward we are likely going to retire the macosforge repository in favor of the github one.
> 
> That seems very reasonable and would make sense I think, there doesn’t seem to be much rationale for overlap.
> 
>> 
>>> 
>>> I have a few questions on how (particularly Apple folks) view this going forward:
>>> 
>>> First, the previous port to Linux/Solaris of libdispatch was dependent on libkqueue and more importantly on libpthread_workqueue (to have some heuristics for managing the number of threads when lacking kernel support).
>>> 
>>> How do you view this, would you consider integrating support for libpthread_workqueue, or would you have another preference for how to manage this on other platforms (Linux for starters, but essentially any lacking the pthread_workqueue interface)?
>> 
>> yes, staying with libpthread_workqueue is the focus of the current Linux porting effort, but it may make sense to move to something more native over time, e.g. like on FreeBSD where a version of the kernel workqueue was implemented natively.
> 
> Ok, that’s great - previously there was a discussion to actually integrate libpthread_workqueue at least directly into the libdispatch project to reduce the number of dependencies to get a reasonably working libdispatch running - currently Mark Heily put it up on GitHub as well at https://github.com/mheily/libpwq - it has been quite dormant for the last few years, but I think that is largely due to things working reasonably well.
> 
> So would such more close integration be desirable to make things build more out of the box, or would you prefer to only use it if found during build time on the current host? (I would probably prefer the first option, as it essentially just provides support for functionality that the underlying platform lacks - the current libpwq supports a few platforms…).

Hi,

FWIW, this is my personal, let’s call it enlightened, opinion, based on my knowledge of dispatch and my past extensive system programming experience with Linux before I joined Apple.

I think that long term, the best way to maintain a Linux libdispatch port is to go away from the libkqueue that tries to emulate kqueue fully, where dispatch only needs a small subset of the surface of kqueue. Given how source.c is written today, this is not a very small undertaking, but eventually dispatch source map to epoll_ctl(EPOLLONESHOT) very very well.

Given our experience with the work queue subsystem in Darwin, I think that it would make sense to integrate both projects together, as work queue are not that useful if you don’t have dispatch with it, and having it separate gives you all the woes of a stable interface, which you don’t really care for in the first place. It’s probably much better to integrate it and not care about backward and forward compatibility and make it a private library of dispatch on linux. And to not be tied to a given interface at all.

I also think that having a minimal kernel support for thread pool management isn’t that hard to write as a kernel module, I had started to work on this a very long time ago, using the KVM scheduling hooks that let you know when a thread blocks and/or becomes runnable[1]. Threads would declare to that interface that they are work queue threads, and get load information that the thread pool can use to regulate. It’s old code, maybe (probably?) not the right way to do it, but that’s an example of things you can do if you move away from the contrived interface from what libpthread_workqueue exposes. My idea required a linux adjustment that I posted to the LKML at the time (http://lkml.iu.edu/hypermail/linux/kernel/1112.2/00235.html) not sure if it ever made it to mainline (looks like it didn’t).


[1] http://git.madism.org/?p=~madcoder/pwqr.git;a=blob;f=kernel/pwqr.c;h=6d822ea6bca40a2ba8de3965526f33b4a98b8649;hb=HEAD


-Pierre