> On Dec 8, 2015, at 9:05 AM, Daniel A. Steffen via swift-corelibs-dev > <swift-corelibs-dev@swift.org> wrote: > >> >> On Dec 8, 2015, at 6:11, Joakim Hassila <joakim.hass...@orc-group.com> wrote: >> >> Hi Daniel, >> >> >>> On 7 dec. 2015, at 23:11, Daniel A. Steffen <d...@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 _______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
