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

[Pierre Habouzit]

> On Dec 8, 2015, at 9:05 AM, Daniel A. Steffen via swift-corelibs-dev <swift-corelibs-dev at swift.org> wrote:
> 
>> 
>> On Dec 8, 2015, at 6:11, Joakim Hassila <Joakim.Hassila at orc-group.com> 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…).
> 
> That seems like a good idea in principle, I agree that it makes good technical sense given libdispatch is presumably the only client of this library, but short term continuing to keep it separate will likely be easiest (for boring non-technical reasons)
> 
> In particular I’ll have to figure out what the situation would be with us continuing to take changes internally from the github repo after importing a whole contributed project into it (as opposed to incremental patches to the existing sourcebase), ideally I would really prefer to not significantly diverge from our internal repo to make that process as straightforward as possible (essentially a git merge…)

That is a good point.

Merging the codebases doesn’t necessarily require that they live in the same source repository though. I’m just arguing that if the worqueue code/emulation/layer is meant to only have dispatch as a client it allows for something more flexible.

-Pierre