From: Peter Dimov [mailto:pdimov@mmltd.net]
What does the Boost community think of
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n2090.html http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n2094.html http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n2096.html
1. Two different classes "future" and "task" with so simple goals and with a difference of just a single method's return type (almost). What do you think about some more lightweight approach? A new future's method (future::move_result() e.g.) instead of class "task"? Template parameter? Something else? Of course, if it's possible from implementation point of view. 2. Naming. I think "future" and "task" names doesn't reflect the difference between them. More self-explanatory names can simplify learning. OTOH, I don't like the name "future". Of course, it's possible that I'm not very familiar with parallel computing terminology, don't beat pls, but it's completely new multithreading term for me that doesn't raise any contiguity with threads and parallelism. "Task" is wider-popular term IMHO, but "task" in case of N2094 is just an optimization of "future". What about: "task" (instead of "future") and "movable_task", or "copyable_task" and "movable_task", or task<copyable> and task<movable> (pls see #1). 3. Functionality. Original boost::thread simplified multithreading programming because was: 1) portable 2) carefully designed Presented proposals go further on this way, because provide: 1) an ability to return results and to catch an exception (more about this later) 2) thread termination, if I've understood correctly But neither boost::thread nor proposals doesn't significantly simplify multithreading development. What about thread-safe message-queues and concurrency used in functional languages, e.g. erlang? Can you point me to any discussions about this topic? 4. Looping threads. Proposed design is best-suited for "single-task" threads. You have a task and you'd like to do it in a separate thread. This task has a result, and proposed design accents this. It's can be specific enough, but most of my threads work in loop, taking messages from the queue or just "working" until client explicitly stops them, and so doesn't have any results. So why I should worry about this, where's an interface for me? :) It's possible all this questions were many times discussed in the past, so pls refer me. Best regards, Andriy Tylychko, telia@vichnavich.com