< repost [with repaired link] > Peter Dimov wrote: [...] > > Another alternative might allow all of the following: > > > > async_call<int> f(create_thread(), bind(g,1,2)); > > int r = f(); > > > > async_call<int> f(thread_pool(), bind(g,1,2)); > > int r = f(); > > Using an undefined-yet Executor concept for the first argument. This is not > much different from > > async_call<int> f( bind(g, 1, 2) ); > // execute f using whatever Executor is appropriate > int r = f.result(); > > except that the async_call doesn't need to know about Executors.
Yep. http://gee.cs.oswego.edu/dl/concurrent/dist/docs/java/util/concurrent/ThreadExecutor.html But I >>still insist<< ( ;-) ) on a rather simple interface for creating a thread object (that shall kinda-"encapsulate" that "async_call<T>"-thing "representing" the thread routine with its optional parameter(s) and return value... and which can be canceled [no-result-ala-PTHREAD_CANCELED] and timedout- on-timedjoin() -- also "no result" [reported by another "magic" pointer value]): http://groups.google.com/groups?selm=3D5D59A3.E6C97827%40web.de (Subject: Re: High level thread design question) http://groups.google.com/groups?selm=3D613D44.9B67916%40web.de (Well, "futures" aside for a moment, how about the following...) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ;-) ;-) regards, alexander. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
