[swift-corelibs-dev] libdispatch roadmap and api addition proposal
Joakim.Hassila at orc-group.com
Thu Dec 10 02:36:05 CST 2015
On 8 dec. 2015, at 18:05, Daniel A. Steffen <das at apple.com> wrote:
>> On Dec 8, 2015, at 6:11, Joakim Hassila <Joakim.Hassila at orc-group.com> wrote:
>> 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…)
Right - would perhaps be good to try to have some guidelines on how such integration should be done in general (hopefully support for additional platforms will be added over time, so it would be good to have a systematic approach to how to do the platform specific changes without breaking your merge process completely - I think that is in everyones interest). Would you make a suggestion on what would work well in practice later for long-term?
Out of curiosity on a more philosophical note - do you view the libdipsatch internal repo or the GitHub one to be ‘upstream’? In the Ars interview, Craig Federighi said "The Swift team will be developing completely in the open on GitHub” which implied the GitHub version being the ‘upstream’ one - how you view that for libdispatch would possibly impact the ‘divergence’ aspect… I understand the answer can well be different for various reasons...
This e-mail is confidential and may contain legally privileged information. It is intended only for the addressees. If you have received this e-mail in error, kindly notify us immediately by telephone or e-mail and delete the message from your system.
More information about the swift-corelibs-dev