[swift-corelibs-dev] Cancelable DispatchQueue.concurrentPerform

[Karl Wagner via swift-corelibs-dev]

Would it be possible to make a cancelable version of 
DispatchQueue.concurrentPerform, allowing you to abort any yet-to-be-scheduled 
blocks?

The use-case is for when you’re concurrently performing a job and one of them 
sets a flag or fails in a way which already defines the result. Further 
execution wouldn’t affect the outcome, so it would be nice if an operation 
could flag back to concurrentPerform that it doesn’t have to schedule any more 
jobs.

For a real-world example, see this concurrent RandomAccessCollection wrapper I 
was building: https://gist.github.com/karwa/43ae838809cc68d317003f2885c71572 


It would be beneficial if we could stop early in the case of errors (see: 
_forEach), or if some global flag is set (see: contains).

- Karl___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

[Mamatha Busi via swift-corelibs-dev]

Hello Created a PR https://github.com/apple/swift-corelibs-foundation/pull/889 for the XDG file specification implementation, extending from the work Tony Parker shared below. But still the question remains as to how we could test this without adding exposed API from the Foundation side. We could identify the usage of the XDG Environmental variables in already existing API of Foundation. For example:  HTTPCookieStorage would use XDG_CONFIG_HOME or XDG_DATA_HOME. Although, not sure that we can find usage for the entire specification.Any other ideas to get the tests done? Thanks!CheersMamatha-swift-corelibs-dev-boun...@swift.org wrote: -To: Pushkar N Kulkarni From: Tony Parker via swift-corelibs-dev Sent by: swift-corelibs-dev-boun...@swift.orgDate: 01/23/2017 11:08PMCc: Will Stanton , swift-corelibs-dev Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorageHere is the branch where I started the work but didn’t get too far.https://github.com/parkera/swift-corelibs-foundation/tree/parkera/xdg_implementationOne tricky part is that we need to figure out a way to test this stuff without exposing public API from file manager…- TonyOn Jan 23, 2017, at 2:09 AM, Pushkar N Kulkarni  wrote:Hi Tony, Thanks! A starting point will really help. I've filed a feature request on JIRA: https://bugs.swift.org/browse/SR-3697Pushkar N Kulkarni,IBM RuntimesSimplicity is prerequisite for reliability - Edsger W. Dijkstra-anthony.par...@apple.com wrote: -To: Pushkar N Kulkarni From: Tony Parker Sent by: anthony.par...@apple.comDate: 01/20/2017 11:28PMCc: Will Stanton , swift-corelibs-dev Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorageYup, I think that makes sense.I started an implementation a bit ago but didn’t get very far before I got derailed onto some other topics. I’ll see if I can clean it up and put it somewhere as a starting point.- TonyOn Jan 20, 2017, at 2:31 AM, Pushkar N Kulkarni  wrote:Hi Tony, Will, others: Apologies for bringing this up after a long time!I hope we still agree on the use of the "XDG Base Directory Specification". I did a quick read of the spec document. I am happy to file a JIRA report for this.The scope, as I understand it is: CoreFoundation will implement the "XDG Base Directory Specification" and present an API to allow Foundation to retrieve the different absolute paths(related to the different env variables defined), which will be used to persist the different kinds of user data.Please do let me know if my understanding is correct. Please augment it if necessary. Thanks!Pushkar N Kulkarni,IBM RuntimesSimplicity is prerequisite for reliability - Edsger W. Dijkstra-swift-corelibs-dev-boun...@swift.org wrote: -To: Will Stanton From: Tony Parker via swift-corelibs-dev Sent by: swift-corelibs-dev-boun...@swift.orgDate: 11/17/2016 03:45AMCc: swift-corelibs-dev Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorageHi Will,> On Nov 14, 2016, at 12:56 PM, Will Stanton  wrote:> > Hello Tony,> > Thanks for the reply. About XDG_DATA_HOME, the variable is undefined on my desktop-less server, and I think many processes still have their own save locations.> Still, I can believe its used in a lot of places (https://github.com/search?q=XDG_DATA_HOME=Code=✓) and am not opposed to it!> > Perhaps SEARCH/$EXECUTABLE_NAME/Preferences.plist would be good place and format for NSUserDefaults with SEARCH = getenv(XDG_DATA_HOME) then ~/.config?> > > What about the path for cookies+caches?I’m just reading this spec for the first time, but it looks like it accounts for that:> • There is a single base directory relative to which user-specific non-essential (cached) data should be written. This directory is defined by the environment variable $XDG_CACHE_HOME.Overall the spec looks reasonable and seems to be close to what we we would need.A great next step would be to file a JIRA and look for volunteers who want to help implement this in SCL-Foundation.- Tony> > Regards,> Will Stanton> >> On Nov 14, 2016, at 2:37 PM, Tony Parker via swift-corelibs-dev  wrote:>> >> Off-list, someone pointed me here:>> >> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html>> >> and here:>> >> http://stackoverflow.com/questions/1024114/location-of-ini-config-files-in-linux-unix>> >> Noting that there seems to be a growing consensus for $HOME/.config.>> >> Is this spec beginning to be used in the real world?> ___swift-corelibs-dev mailing