Make API match what's in our SC Ads

[bholt]

Specifically, make sure we have working:

void finish([]{ });
void forall(int64_t,size_t,[](int64_t){ });
void forall(GlobalAddress<T>,size_t,[](T&){ });

[bholt]

As another note, we need a clean way to express "async" versions of forall.

We could do just:

void forall_async(...);

Or, it would be cool if we could get away with template tags:

forall<async>();
forall<async,public>();

I'm not sure how to implement this, it'd take some clever templating. Maybe something like:

enum SyncMode {
  blocking;
  async;
};

template< SyncMode S = blocking >
void forall(/*...*/) { /*...*/ }

Note: for the syntax shown above, it can't be enum class, otherwise we'd have to say forall<SyncMode::async>()...

[bmyerz]

To me the difference in API syntax is not huge, so I think it comes down to whether the implementation code is easier to maintain by using template tags to enumerate the combinations.

[bholt]

I guess I'm thinking it's useful for maintenance once you have more than one. I hashed out a test: https://gist.github.com/bholt/7539752#file-spawn-cpp.

It also seems like it would be easier from a user perspective than remembering underscore name variants, especially if it was more universal (like if we used the same async thing for delegates, etc).

[nelsonje]

I like the type tags too, for the same reasons; it makes the interfaces a bit more orthogonal.

This is related to the question about how to specify the right joiner. Does that need to be dynamic? Does it make sense to support multiple overlapping joiners?

[bholt]

One fairly glaring problem with the finish syntax used in the SC stuff is that it makes it look like you can do nested finish blocks, but in fact it’s implemented coarsely using the GCE.

Dynamic GCEs might allow us to dynamically create new GCE’s and then swap them out under the hood to make it appear like you’re getting scoped finishes.

[bholt]

Okay, I think all of this is in place now, with Pull #130 and df58461.