Sorry for late reply... had a hard disk problem that prevented accessing
e-mail.
Peter Dimov said:
William E. Kempf wrote:
How about this compromise:
template typename R
class async_call
{
public:
template typename F
explicit async_call(const F f)
: m_func(f)
{
Peter Dimov said:
William E. Kempf wrote:
It's not just the efficiencies that concern me with dynamic
allocation. It's the additional points of failure that occur in this
case as well. For instance, check out the article on embedded coding
in the most recent CUJ (sorry, don't have the
David Abrahams wrote:
Peter Dimov [EMAIL PROTECTED] writes:
I am not saying that this is never useful, but syntax should target
the typical scenario, not corner cases.
Agreed. I suppose that you'll say it doesn't target the typical
scenario because of its confusability. I wouldn't argue.
Peter Dimov [EMAIL PROTECTED] writes:
David Abrahams wrote:
Peter Dimov [EMAIL PROTECTED] writes:
I am not saying that this is never useful, but syntax should target
the typical scenario, not corner cases.
Agreed. I suppose that you'll say it doesn't target the typical
scenario because
David Abrahams wrote:
Peter Dimov [EMAIL PROTECTED] writes:
We have three concepts: Runnable, Executor (executes Runnables), and
HasResult (for lack of a better name.) The AsyncCall concept I had
in mind is both Runnable and HasResult, so it can't use operator()
for both. x.result() or
William E. Kempf [EMAIL PROTECTED] writes:
Actually, there's another minor issue as well. The user can call
operator() and then let the async_call go out of scope with out ever
calling result(). Mayhem would ensue. The two options for dealing
with this are to either block in the destructor
From: David Abrahams [EMAIL PROTECTED]
Date: 2003/02/10 Mon AM 11:15:31 EST
To: Boost mailing list [EMAIL PROTECTED]
Subject: Re: [boost] Re: A new boost::thread implementation?
William E. Kempf [EMAIL PROTECTED] writes:
Actually, there's another minor issue as well. The user can
William E. Kempf [EMAIL PROTECTED] writes:
From: David Abrahams [EMAIL PROTECTED] Date: 2003/02/10
Mon AM 11:15:31 EST To: Boost mailing list [EMAIL PROTECTED]
Subject: Re: [boost] Re: A new boost::thread implementation?
William E. Kempf [EMAIL PROTECTED] writes:
Actually, there's
William E. Kempf wrote:
From: Peter Dimov [EMAIL PROTECTED]
// step 2: execute an async_call
call();
This example, and the implementation above, are just complex
synchronous calls. I assume you really meant for either the
constructor or this call to also take an Executor concept?
Peter Dimov [EMAIL PROTECTED] writes:
Unspecified, but I don't think we can avoid that with the low-level
interface. High level wrappers that package creation and execution would be
immune to this problem.
Is there really a need for a low-level async_call interface? After
all, the existing
From: Peter Dimov [EMAIL PROTECTED]
Date: 2003/02/10 Mon PM 12:54:28 EST
To: Boost mailing list [EMAIL PROTECTED]
Subject: Re: Re: [boost] Re: A new boost::thread implementation?
William E. Kempf wrote:
From: Peter Dimov [EMAIL PROTECTED]
// step 2: execute an async_call
David Abrahams wrote:
Peter Dimov [EMAIL PROTECTED] writes:
Unspecified, but I don't think we can avoid that with the low-level
interface. High level wrappers that package creation and execution
would be immune to this problem.
Is there really a need for a low-level async_call interface?
From: David Abrahams [EMAIL PROTECTED]
William E. Kempf [EMAIL PROTECTED] writes:
I lean towards simple undefined behavior. How do you feel about it?
I have a feeling that I'm not being asked here, and maybe even that
it's wasted breath because you've grown tired of my emphasis on a
David Abrahams wrote:
Peter Dimov [EMAIL PROTECTED] writes:
David Abrahams wrote:
Peter Dimov [EMAIL PROTECTED] writes:
Unspecified, but I don't think we can avoid that with the low-level
interface. High level wrappers that package creation and execution
would be immune to this problem.
William E. Kempf wrote:
How about this compromise:
template typename R
class async_call
{
public:
template typename F
explicit async_call(const F f)
: m_func(f)
{
}
void operator()()
{
mutex::scoped_lock lock(m_mutex);
if (m_result)
William E. Kempf wrote:
It's not just the efficiencies that concern me with dynamic
allocation. It's the additional points of failure that occur in this
case as well. For instance, check out the article on embedded coding
in the most recent CUJ (sorry, don't have the exact title handy).
William E. Kempf [EMAIL PROTECTED] writes:
From: David Abrahams [EMAIL PROTECTED]
Peter Dimov [EMAIL PROTECTED] writes:
It's a tool that allows high-level interfaces to be built. Whether
people will want/need to build their own high-level interfaces is
another story.
I think it's a
William E. Kempf [EMAIL PROTECTED] writes:
No, I was asking anyone interested in responding, and you're certainly
not wasting your breath. I think I reached a compromise on these
issues/questions, and would appreciate your response (it's in another
post).
Done.
Allocation can be pretty
Peter Dimov [EMAIL PROTECTED] writes:
I can. On the other hand, I can implement the thread primitives and
optional, too. The point is that if, while building a high-level interface
implementation, we discover an useful low-level primitive that offers
greater expressive power (if less safety),
David Abrahams wrote:
[...]
Well, I don't really feel like arguing about this much longer.
I'd love to contribute to this discussion but there's no firm ground to
stand on. What _are_ the concepts being discussed? I think I see
AsyncCallR
AsyncCall(functionR () f);
void operator()();
Peter Dimov [EMAIL PROTECTED] writes:
David Abrahams wrote:
[...]
Well, I don't really feel like arguing about this much longer.
I'd love to contribute to this discussion but there's no firm ground to
stand on. What _are_ the concepts being discussed? I think I see
AsyncCallR
David Abrahams wrote:
Peter Dimov [EMAIL PROTECTED] writes:
David Abrahams wrote:
[...]
Well, I don't really feel like arguing about this much longer.
I'd love to contribute to this discussion but there's no firm ground
to stand on. What _are_ the concepts being discussed? I think I
Peter Dimov [EMAIL PROTECTED] writes:
David Abrahams wrote:
That's the general idea. Of course we can haggle over the syntactic
details, but the main question is whether you can get a return value
from invoking a thread function or whether you have to declare some
global state and ask the
David Abrahams wrote:
Peter Dimov [EMAIL PROTECTED] writes:
With the above AsyncCall:
async_callint f( bind(g, 1, 2) ); // can offer syntactic sugar here
thread t(f); // or thread(f); for extra cuteness
int r = f.result();
The alternative seems to be
async_callint f( bind(g, 1, 2) );
Peter Dimov [EMAIL PROTECTED] writes:
David Abrahams wrote:
Peter Dimov [EMAIL PROTECTED] writes:
With the above AsyncCall:
async_callint f( bind(g, 1, 2) ); // can offer syntactic sugar here
thread t(f); // or thread(f); for extra cuteness
int r = f.result();
The alternative seems to
David Abrahams wrote:
Peter Dimov [EMAIL PROTECTED] writes:
Using an undefined-yet Executor concept for the first argument. This
is not much different from
async_callint f( bind(g, 1, 2) );
// execute f using whatever Executor is appropriate
int r = f.result();
except that the async_call
David Abrahams said:
William E. Kempf [EMAIL PROTECTED] writes:
David Abrahams said:
...and if it can't be default-constructed?
That's what boost::optional is for ;).
Yeeeh. Once the async_call returns, you have a value, and should be
able to count on it. You shouldn't get back an
David Abrahams said:
Peter Dimov [EMAIL PROTECTED] writes:
David Abrahams wrote:
Peter Dimov [EMAIL PROTECTED] writes:
With the above AsyncCall:
async_callint f( bind(g, 1, 2) ); // can offer syntactic sugar
here thread t(f); // or thread(f); for extra cuteness
int r = f.result();
The
Alexander Terekhov [EMAIL PROTECTED] writes:
But I still insist ( ;-) ) on a rather simple interface
for creating a thread object (that shall kinda-encapsulate
that async_callT-thing representing the thread routine
with its optional parameter(s) and return value... and which
can be
Peter Dimov [EMAIL PROTECTED] writes:
except that the async_call doesn't need to know about Executors.
...and that you don't need a special syntax to get the result out that
isn't compatible with functional programming. If you want to pass a
function object off from the above, you need
William E. Kempf [EMAIL PROTECTED] writes:
except that the async_call doesn't need to know about Executors.
...and that you don't need a special syntax to get the result out that
isn't compatible with functional programming. If you want to pass a
function object off from the above, you need
David Abrahams said:
Peter Dimov [EMAIL PROTECTED] writes:
The line in the middle won't work, actually, but that's another story.
boost::thread() creates a handle to the current thread. ;-) Score
another one for defining concepts before using them.
Oh, I'm not up on the new interface. How
William E. Kempf [EMAIL PROTECTED] writes:
David Abrahams said:
William E. Kempf [EMAIL PROTECTED] writes:
David Abrahams said:
...and if it can't be default-constructed?
That's what boost::optional is for ;).
Yeeeh. Once the async_call returns, you have a value, and should be
able to
Darryl Green said:
-Original Message-
From: William E. Kempf [mailto:[EMAIL PROTECTED]]
Dave Abrahams said:
Hm? How is the result not a result in my case?
I didn't say it wasn't a result, I said that it wasn't only a
result.
In your case it's also the call.
Regardless of
David Abrahams said:
...and if it can't be default-constructed?
That's what boost::optional is for ;).
Yeeeh. Once the async_call returns, you have a value, and should be able
to count on it. You shouldn't get back an object whose invariant allows
there to be no value.
I'm not sure I can
William E. Kempf [EMAIL PROTECTED] writes:
David Abrahams said:
...and if it can't be default-constructed?
That's what boost::optional is for ;).
Yeeeh. Once the async_call returns, you have a value, and should be able
to count on it. You shouldn't get back an object whose invariant
double d;
threaddouble t = spawn(foo)(a,b,c);
// do something else
d = thread.return_value();
A solution like this has been proposed before, but I don't like it.
This creates multiple thread types, instead of a single thread type.
I think this will only make the
From: Wolfgang Bangerth [EMAIL PROTECTED]
double d;
threaddouble t = spawn(foo)(a,b,c);
// do something else
d = thread.return_value();
A solution like this has been proposed before, but I don't like it.
This
creates multiple thread types, instead of a single
From: Wolfgang Bangerth [EMAIL PROTECTED]
This does the same, indeed. Starting a thread this way is just a
little more complex (and -- in my view -- less obvious to read) than
writing
thread t = spawn(foo)(a,b,c);
But that's just personal opinion, and I'm arguably biased :-)
I'm sure
From: William E. Kempf [EMAIL PROTECTED]
From: Wolfgang Bangerth [EMAIL PROTECTED]
This does the same, indeed. Starting a thread this way is just a
little more complex (and -- in my view -- less obvious to read) than
writing
thread t = spawn(foo)(a,b,c);
But that's just personal
async_resultdouble res;
thread t(bind(res.call(), a, b, c));
// do something else
d = res.value(); // Explicitly waits for the thread to return a
value?
This does the same, indeed. Starting a thread this way is just a little
more complex (and -- in my view -- less obvious to
Dave Abrahams said:
Hmm... that would be
an interesting alternative implementation. I'm not sure it's as
obvious as the syntax I suggested
Sorry, IMO there's nothing obvious about your syntax. It looks
cumbersome and low-level to me. Let me suggest some other syntaxes for
async_result,
On Thursday, February 06, 2003 12:33 PM [GMT+1=CET],
William E. Kempf [EMAIL PROTECTED] wrote:
Dave Abrahams said:
Hmm... that would be
an interesting alternative implementation. I'm not sure it's as
obvious as the syntax I suggested
Sorry, IMO there's nothing obvious about your
Dave Abrahams said:
On Thursday, February 06, 2003 12:33 PM [GMT+1=CET],
William E. Kempf [EMAIL PROTECTED] wrote:
Dave Abrahams said:
Hmm... that would be
an interesting alternative implementation. I'm not sure it's as
obvious as the syntax I suggested
Sorry, IMO there's nothing
Hi Ove,
f. It shall be possible to send extra information, as an optional
extra argument
to the boost::thread ctor, to the created thread.
boost::thread::self shall offer a method for retrieving this extra
information. It is not required that this information be passed in
a
45 matches
Mail list logo
