Peter Dimov said:
> William E. Kempf wrote:
R result() const
{
boost::mutex::scoped_lock lock(m_mutex);
while (!m_result)
m_cond.wait(lock);
>>>
>>> This changes result()'s semantics to "block until op() finishes";
>>> what happens if no
William E. Kempf wrote:
> Sorry for late reply... had a hard disk problem that prevented
> accessing e-mail.
>
> Peter Dimov said:
>> William E. Kempf wrote:
[...]
>>> void operator()()
>>> {
>>> mutex::scoped_lock lock(m_mutex);
>>> if (m_result)
>>> throw "ca
David Abrahams said:
> "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 int
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 ha
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
>> class async_call
>> {
>> public:
>> template
>> explicit async_call(const F& f)
>> : m_func(f)
>> {
"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 s
"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
"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 stor
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 wrote:
>
> How about this compromise:
>
> template
> class async_call
> {
> public:
> template
> explicit async_call(const F& f)
> : m_func(f)
> {
> }
>
> void operator()()
> {
> mutex::scoped_lock lock(m_mutex);
> if (m_result)
>
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
> 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 emph
> 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 valuable question to ask whethe
"William E. Kempf" <[EMAIL PROTECTED]> writes:
>> > Sort of... I was thinking about the refactoring where you don't hold
>> > the mutex the entire time the function is being called. But even
>> > with out the refactoring, there is some room for error:
>> >
>> > thread1: call()
>> > thread2: call(
"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.
>>
>
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
>
> 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:
> >>
"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 exis
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 ta
> 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?
>
"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?
>&g
>
> 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:
>
William E. Kempf wrote:
>> Here's some compilable code, to put things in perspective:
>
> Thanks. This helps me, at least.
>
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>>
>> template class async_call
>> {
>> public:
>>
>> template explicit async_call(F f): f_
"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 des
>
> From: "Peter Dimov" <[EMAIL PROTECTED]>
> Date: 2003/02/10 Mon AM 09:08:08 EST
> To: "Boost mailing list" <[EMAIL PROTECTED]>
> Subject: Re: [boost] Re: A new boost::thread implementation?
>
> David Abrahams wrote:
> > "Peter
"Peter Dimov" <[EMAIL PROTECTED]> writes:
> 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 HasResu
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.resu
"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 typic
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 woul
"Peter Dimov" <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>>
>>> David Abrahams said:
No, my fault. Syntactically, I should've written this:
async_call f(create_thread(), bind(g,1,2));
int r = f();
>>>
>>> Do yo
David Abrahams wrote:
> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>
>> David Abrahams said:
>>> No, my fault. Syntactically, I should've written this:
>>>
>>> async_call f(create_thread(), bind(g,1,2));
>>> int r = f();
>>
>> Do you want it to be "int r = f();" or just "int r = f;" or
> -Original Message-
> From: William E. Kempf [mailto:[EMAIL PROTECTED]]
>
> > .. borrowing Dave's async_call syntax and Alexander's
> > semantics (which aren't really any different to yours):
>
> Dave's semantics certainly *were* different from mine (and the Futures
> link posted by Alexa
"William E. Kempf" <[EMAIL PROTECTED]> writes:
>> I don't care if you have an "uninitialized" optional internally to the
>> future. The point is to encapsulate that mess so the user doesn't have
>> to look at it, read its documentation, etc.
>
> I think there's some serious misunderstanding here.
"William E. Kempf" <[EMAIL PROTECTED]> writes:
>> I don't care if you have an "uninitialized" optional internally to the
>> future. The point is to encapsulate that mess so the user doesn't have
>> to look at it, read its documentation, etc.
>
> I think there's some serious misunderstanding here.
"William E. Kempf" <[EMAIL PROTECTED]> writes:
> David Abrahams said:
>> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>> int r = async_call(create_thread(), bind(g, 1, 2));
>>
>> int r = async(boost::thread(), g, 1, 2);
^^^
David Abrahams said:
> "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 ;).
>
> Yee
David Abrahams said:
> "William E. Kempf" <[EMAIL PROTECTED]> writes:
> int r = async_call(create_thread(), bind(g, 1, 2));
>
> int r = async(boost::thread(), g, 1, 2);
>>>^^^
>
> int r = async_call(rpc(some_machine), bind
David Abrahams wrote:
[...]
> Oh, I'm not up on the new interface. How are we going to create a
> new thread?
"KISS": new_thread factories. Please.
regards,
alexander.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boos
"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, y
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 in
"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 a
"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,
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_call"-thing "representing" the thread routine
> with its optional parameter(s) and return value... and which
David Abrahams said:
> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>
>> David Abrahams wrote:
>>> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>>>
With the above AsyncCall:
async_call f( bind(g, 1, 2) ); // can offer syntactic sugar
here thread t(f); // or thread(f); for extra cuten
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.
< repost [with repaired link] >
Peter Dimov wrote:
[...]
> > Another alternative might allow all of the following:
> >
> > async_call f(create_thread(), bind(g,1,2));
> > int r = f();
> >
> > async_call f(thread_pool(), bind(g,1,2));
> > int r = f();
>
> Using an undefined-yet Ex
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_call f( bind(g, 1, 2) );
>> // execute f using whatever Executor is appropriate
>> int r = f.result();
>>
>> except t
"Peter Dimov" <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>>
>>> With the above AsyncCall:
>>>
>>> async_call f( bind(g, 1, 2) ); // can offer syntactic sugar here
>>> thread t(f); // or thread(f); for extra cuteness
>>> int r = f.result();
>>>
David Abrahams wrote:
> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>
>> With the above AsyncCall:
>>
>> async_call 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_call f( bi
"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" sta
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
"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
>
> AsyncCa
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
AsyncCall
AsyncCall(function f);
void operator()();
// eff
"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
"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
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 no
"William E. Kempf" <[EMAIL PROTECTED]> writes:
> Dave Abrahams said:
>> On Thursday, February 06, 2003 12:33 PM [GMT+1=CET],
>> William E. Kempf <[EMAIL PROTECTED]> wrote:
>>
> 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.
OK.
>>> An
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.
>
> -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 whether it invok
Dave Abrahams wrote:
[...]
> > 2) You're still hiding the thread creation.
>
> Absolutely. High-level vs. low-level.
Yeah ...
>
> > This is a mistake to me for
> > two reasons. First, it's not as obvious that a thread is being created
> > here (though the new names help a lot).
>
> Unimport
> > > async_result later = spawn(foo)(a, b, c);
> >
> > Mustn't use the name spawn() here. It implies a thread/process/what ever
> > has been spawned at this point, which is not the case. Or has it (he says
> > later, having read on)?
>
> It has.
It must, because a/b/c might be temporaries.
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
>> >
>> >
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 "o
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 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 o
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);
> >>
> >>
> 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
From: "Wolfgang Bangerth" <[EMAIL PROTECTED]>
> > > double d;
> > > thread 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
>
>> > double d;
>> > thread 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
Wolfgang Bangerth wrote:
[...]
> > async_result 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
> > double d;
> > thread 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 th
>
> 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
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 typ
73 matches
Mail list logo
