Le 2010-09-10 à 21:01, David Simcha a écrit : > This is getting me thinking. I've given up making most of std.parallelism > safe. Parallel foreach is the hardest thing to make safe, and for me > personally the most useful part of std.parallelism. I wonder, though, if I > can make Task @safe/@trusted provided: > > 1. The input args are either indirection-free, immutable, or shared. > > 2. The callable is a function pointer, not a delegate, alias or class with > overloaded opCall.
Couldn't it be a shared delegate too (a delegate to a shared member)? > 3. The return type is either indirection-free, immutable or shared. (This > is, unfortunately, necessary b/c the worker thread could in theory hold onto > a reference to it in TLS after returning, even though doing so would be > thoroughly idiotic in most cases.) > > I'm thinking I may add a safeTask() function that is marked @trusted, and > creates a Task object iff these constraints are satisfied (and otherwise > doesn't compile). I think the only sane way to do this is to have a separate > safe function for creating tasks in addition to the more lenient "here be > dragons" one. The only major thing I don't like about this is the idea of > sprinkling a few safe functions in a mostly "here be dragons" module. It > seems like it would complicate code reviews. Perhaps the safe parts of tasks and thread pools could be put in std.concurrency, and the unsafe parts necessary for std.parallelism could be built on top of it and reside std.parallelism (which could just cast its delegates to shared delegates to bypass the safeties). -- Michel Fortin [email protected] http://michelf.com/ _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
