Section: 32.10 [futures] Status: Resolved Submitter: Switzerland Opened: 2010-08-25 Last modified: 2016-01-28
Priority: Not Prioritized
View all other issues in [futures].
View all issues with Resolved status.
Discussion:
Addresses CH-36
Providing only three different possible values for the enum
launch and saying that launch::any means either
launch::sync or launch::async is very restricting. This
hinders future implementors to provide clever
infrastructures that can simply by used by a call to
async(launch::any,...). Also there is no hook for an
implementation to provide additional alternatives to launch
enumeration and no useful means to combine those (i.e.
interpret them like flags). We believe something like
async(launch::sync | launch::async, ...) should be allowed
and can become especially useful if one could say also
something like async(launch::any & ~launch::sync, ....)
respectively. This flexibility might limit the features usable
in the function called through async(), but it will allow a
path to effortless profit from improved hardware/software
without complicating the programming model when just
using async(launch::any,...)
[ Resolution proposed by ballot comment: ]
Change in 32.10.1 [futures.overview] 'enum class launch' to allow
further implementation defined values and provide
the following bit-operators on the launch values
(operator|, operator&, operator~ delivering a
launch value).
launch enums,
but we shouldn't limit the standard to just 32 or 64
available bits in that case and also should keep
the launch enums in their own enum namespace.
Change [future.async] p3 according to the
changes to enum launch. change --launch::any to
"the implementation may choose any of the
policies it provides." Note: this can mean that an
implementation may restrict the called function to
take all required information by copy in case it will
be called in a different address space, or even, on
a different processor type. To ensure that a call is
either performed like launch::async or
launch::sync describe one should call
async(launch::sync|launch::async,...)
[ 2010-11-02 Daniel comments: ]
The new paper n3113 provides concrete wording.
Proposed resolution:
Resolved by n3188.