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

[Kevin Ballard]

On Mon, Dec 7, 2015, at 04:55 AM, Joakim Hassila via swift-corelibs-dev wrote:
> 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.

I actually have an outstanding radar asking for this exact
functionality. My proposal called it `dispatch_try_sync()`, which didn't
actually call the dispatch_async() automatically but simply returned a
boolean value telling you if it ran the code. My use-case here wasn't
actually that I wanted to run the code async, but that I needed to do
two operations on a realtime thread in any order, one of which needed to
be on a queue, so I wanted to do something like

BOOL done = dispatch_try_sync(queue, ^{ ... }); do_other_work(); if
(!done) {    dispatch_sync(queue, ^{ ... }); }

My radar is still open (rdar://problem/16436943), but it got a response
as follows:

> I think the best way to "emulate" this is to use a DATA_OR source, and
> not semaphores or other things like that.
>
> Most of the issues that I've seen with trylock() tends to be uses
> looking like this:
>
> again:  if (trylock()) {    do {      clear_marker();      do_job();
> } while(has_marker());     unlock();  } else if (!has_marker()) {
> set_marker();    goto again;  }
>
> and all unlockers check for the marker to do the said job before
> unlock basically.
>
> The thing is, most of the people use that wrongly and don't loop
> properly making those coalescing checks racy, that's what dispatch
> DATA_OR sources are for.
>
> Many other uses can also be replaced with a dispatch_async()
>
> and it's very clear that the reporter can do exactly what he wants
> with a DATA_OR source. We should have a way to make sources acts as
> barriers (which I have a patch for) else we only provide half the
> required primitives.
>
> I don't see a compelling use case that can't be solved elegantly with
> data sources today.
>
> Using a DISPATCH_SOURCE_DATA_OR with a latch is a good alternative to
> what you are doing.
>
> We are continuing to work on this issue, and will follow up with
> you again.

-Kevin Ballard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20151207/ce638ae5/attachment.html>