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

[Tony Parker]

Hi Joakim,

> On Dec 7, 2015, at 4:55 AM, Joakim Hassila via swift-corelibs-dev <swift-corelibs-dev at swift.org> wrote:
> 
> Hi,
> 
> I think (and hope) that this is the proper forum for a few questions wrt to libdispatch, otherwise any pointers are appreciated.
> 

Yup, you’re in the right place.

> We are currently using libdispatch extensively on Linux (and Solaris for a while longer…) based on the previous version available from Mac OS forge (with later additions merged from opensource.apple.com) over time.
> 
> 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)?
> 

I think it’s reasonable to continue to depend on libkqueue here where we can. We may have to have some kind of config option to use pure userspace stuff on certain platforms. I’m also open to the idea of getting something with fewer dependencies and lower performance done as an early first step, so we can unblock all of the API above libdispatch that wants to just use queues.

> Secondly, we have extended the public libdispatch API internally with one more flavor of dispatching, let’s call it ‘dispatch_async_inline’ - the semantics being ‘perform the processing of the work synchronously if we wouldn’t block the calling thread, if we would block, instead perform the work as a normal dispatch_async’.
> 
> Would such a change be considered to be integrated, or should we keep our internal diffs indefinitely? Just to understand if it is worth the effort with a nicely packaged pull request or not…

> The rationale for the API is that we are quite latency sensitive and want to use inline processing up until the point where we can’t keep up with the available work, at which point we would switch to asynchronous processing seamlessly (we have multiple producers). This means that the thread calling this API can be stolen for a significant amount of time (emptying the queue it was assigned to), but when the system is under ‘light' load, we don’t need to incur the wakeup penalty for a completely asynchronous dispatch.
> 

Our most important goal for year one is to get the core library implementations up to date with where we are on Darwin on platforms like Linux. API changes are not out of the question but we have to make sure they align with that goal. This is the right place to discuss them, though. We’ll be in a much better place to evaluate it when we get dispatch building & running.

> Cheers,
> 
> Joakim
> 
> PS Big kudos to whoever at Apple is responsible for driving fundamentals like this out as OSS…
> 

Thanks for your interest in the project!

- Tony


> 
> ________________________________
> 
> 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.
> _______________________________________________
> swift-corelibs-dev mailing list
> swift-corelibs-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev