Re: [boost] [threads] Permission given to change to Boost.License

From: Andriy Tylychko \(mail.ru\) (telya_at_[hidden])
Date: 2006-09-18 06:36:39

> From: Peter Dimov [mailto:pdimov_at_[hidden]]
> 
> 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_at_[hidden]