Title
'launch' enum too restrictive
Status
resolved
Section
[futures]
Submitter
Switzerland

Created on 2010-08-25.00:00:00 last changed 170 months ago

Messages

Date: 2011-02-20.22:39:32

Proposed resolution:

Resolved by n3188.

Date: 2010-11-02.00:00:00

[ 2010-11-02 Daniel comments: ]

The new paper n3113 provides concrete wording.

Date: 2010-11-02.20:32:51

[ Resolution proposed by ballot comment: ]

Change in [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).

Note: a possible implementation might use an unsigned value to represent the 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,...)

Date: 2010-10-24.03:04:13

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,...)

History
Date User Action Args
2010-11-18 14:01:09adminsetstatus: nad editorial -> resolved
2010-11-11 19:19:17adminsetstatus: open -> nad editorial
2010-11-02 20:32:51adminsetmessages: + msg5280
2010-11-02 20:32:51adminsetmessages: + msg5279
2010-10-24 03:04:13adminsetmessages: + msg4972
2010-08-25 00:00:00admincreate