ESCAPING_ASYNC property not supported

[DaoWen]

We currently support "escaping" asyncs internally (they're used for our fiber-based finish-scope continuations), but the ESCAPING_ASYNC property does not seem to be supported through the user-facing API.

We should add support for "escaping" asyncs and/or remove the ESCAPING_ASYNC definition. (We don't have to implement this via a property.)

I recommend supporting "escaping" asyncs. Currently, apps that synchronize via DDTs rather than nested finish scopes see a significant amount of contention on the implicit top-level finish scope because very async has to check-in/out of that one finish scope. Using "escaping" asyncs removes this point of contention.

On a side note, I think "escape" might already have a set meaning in the literature, and I'm not sure if this usage conflicts (i.e., I may not have picked the best name for this, and we may want to revisit that topic).

[agrippa]

Ensuring we support escaping asyncs (and adding testing for that) sounds like a good step to me. What is the naming conflict on escape? I'm not familiar with any other meaning.

[DaoWen]

I had trouble finding the reference again when I was opening the issue earlier today, but I tracked it down again. See §3.1 in Work-First and Help-First Scheduling Policies for Async-Finish Task Parallelism.

[agrippa]

Gotcha. Finish-free asyncs? Unregistered asyncs? Floating asyncs? Any other ideas?

[DaoWen]

Scopeless?
Unscoped?
Independent?
Meta? (i.e., an asynchronous async)

I like "meta" just because it's meta.
I think "finish-free" is the most descriptive.
I feel "unscoped" might be the best fit for an API, e.g., PROP_UNSCOPED or async_unscoped(...).

However, it wouldn't surprise me if I had a totally different viewpoint on this in the morning. As long as we don't pick something terrible, I think whatever we choose will grow on us and seem natural after a while.

[agrippa]

If you think finish-free is the most descriptive, I'd go with that one. If we're trying to avoid overloaded terms to begin with, it seems like we'd want to avoid a term as overloaded as "scope".

[DaoWen]

Good point. PROP_NO_FINISH or PROP_NO_FIN would work if we stick with using properties.

[DaoWen]

One thing that might be problematic with supporting finish-free asyncs is how they interact with our termination algorithm. I think it would be up to the user to properly synchronize at the top-level such that the implicit end finish in hclib_finalize does not complete until all the finish-free asyncs return. Since this is an "advanced" feature for optimization, I think that sounds like a reasonable requirement.