Daniel Spangenberg said:
> Hello William!
>
> "William E. Kempf" schrieb:
>
>> You're correct, and the solution is simply to replace the < operator
>> with std::less calls.
>
> You mean the std::less specialization on boost::mutex? (I wasn'
d to an lock exception.
You're correct, and the solution is simply to replace the < operator with
std::less calls.
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
ic. I can't envision an interface that would be both portable and
usable on other platforms. Provide one and I'll certainly consider it.
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Philippe A. Bouchard said:
> William E. Kempf wrote:
>
>>
>> Philippe A. Bouchard said:
>>> William E. Kempf wrote:
>>>
>>> [...]
>>>
>>>> As already pointed out, to associate data with a thread you use
>>>> thread_
Maxim Egorushkin said:
>
> "William E. Kempf" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
>> > Speaking about the timer I ment something like that:
>> >
>> > typedef int milliseconds;
>> >
>> > class s
Philippe A. Bouchard said:
> William E. Kempf wrote:
>
> [...]
>
>> As already pointed out, to associate data with a thread you use
>> thread_specific_ptr. BTW, you still have to remember that the
>> functor is copied, and data passed to/in the functor is not
>&
Maxim Egorushkin said:
>
> "William E. Kempf" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
>> Priorities are implemented, but still undergoing design changes, in
>> the thread_dev branch. The timer, if I understand what you want, is
&
Philippe A. Bouchard said:
> William E. Kempf wrote:
>
> [...]
>
>>> Thanks... but is it possible to obtain the initial address of the
>>> functor object portably, given the current thread object?
>>
>> No, and why would you want to? Especially since
ably have bool return types.
> // ...
>
> };
>
>
>
> I'd really love to have this abilities in the boost::thread.
>
> Please, tell me, whether it's possible?
Difficult to design portably, but possible.
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
..
>> }
>
>
> Thanks... but is it possible to obtain the initial address of the
> functor object portably, given the current thread object?
No, and why would you want to? Especially since it will be a pointer to a
_copy_ of the functor?
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
s, there's a reason for it. Thread clean
up can't be implemented any other way. Read the archives where this
subject gets discussed at least once a month. (I'll add a FAQ entry about
this soon.)
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
t that will break existing code, so I have
to tread lightly here.
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
That's obviously a question for the lawyers, as us laymen will only be
guessing ;).
But it would be nice to just refer to the license instead of repeating it
in every single file.
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
to is basically known
only to the web server. A mapping from a "file://xml/docs/overview.xml"
URI would be useful, however. It should also be fairly trivial.
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Loïc Joly said:
> William E. Kempf wrote:
>>I sympathize, but it's just not reasonable. Again, read the archives.
>
> Thank you for your fast answer !
>
> I did try to look in the archives before posting my mail, but I could no
> find a relevant mail in this hug
Ulrich Eckhardt said:
> On Thursday 12 June 2003 17:05, William E. Kempf wrote:
>> JOLY Loic said:
>> > 1/ Dynamic libraries
>> > Although I compiled boost with the option "-sBUILD=debug release
>> static/dynamic", the library is still generated as a
>
ds are with the C
RTL and not MFC.
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost.Threads. The warnings are known and will
be fixed soon. Ignore them for now.
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
lasses that derive from or uses as member
> variables non-DLL-exported classes is generating some warnings by msvc
> that fall into two categories (4275 and 4251). Would it be possible to
> insert #pragma to remove these spurious warnings ?
I'm addressing this issue.
--
William E. Kempf
f the link first, although my initial
> reaction to CVS was not joyful, but I am sure it can not be that arcane
> to use.
I normally prefer GUIs as well. But in this case, I have to agree with
Dave. You should learn the command line long before using
Stefan Seefeld said:
> William E. Kempf wrote:
>
>> As soon as synchronization relies on *BOTH* a mutex and a sema/event,
>> you've got a race condition.
>
> hmm, I'm not sure I have the same definition for 'race condition' as you
> have. Of course I
Stefan Seefeld said:
> William E. Kempf wrote:
>
>>>so what ? the 'real' queue length is kept private and doesn't matter
>>> much. It's the signaling of the semaphore that makes the change
>>> public.
>>
>>
>> This is a
ized to ensure against race conditions.
> This is my last mail in this thread. It's not related to boost any more
> anyways. We have to agree to disagree.
If you want semaphores to be added to Boost.Threads, the arguments are
very much on topic here.
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Nicolas Fleury said:
> William E. Kempf wrote:
>> Stefan Seefeld said:
>>>As boost doesn't, there must clearly be other reasons for them not to
>>> do that.
>>
>> There is, but the explanations are long and quite complex. That's why
>> the F
is correct, when in fact they have race conditions waiting to
bite them. When Mutexes and Condition variables provide everything that
Semaphores and Events do, but in a way that's easier to use correctly, the
choice to not include Event's or Semaphore's is reasonable.
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Alexander Terekhov said:
>
> "William E. Kempf" wrote:
> [...]
>> Not specifying the exact width
>> of various types is not really something that I think most people
>> would classify as "brain damaged."
>
> That's not the only problem
Vladimir Prus said:
> William E. Kempf wrote:
> Oh.. I misread your post. Apologies. Still, from a practical point of
> view I can hardly imagine that if libxml2 wrapper works, somebody will
> take the time to plug in another backend. That would mean rewriting
> all/most implementa
Stefan Seefeld said:
> William E. Kempf wrote:
>
>> What I think *is* a requirement is that any wrapper library
>> not be tied to a single backend, and I personally believe that what
>> follows from that is that the submission must have at least 2
>> referenced
Vladimir Prus said:
> William E. Kempf wrote:
>
>>> there is no such thing as the 'Gnu licence'. There is the 'GNU
>>> General Public License' (aka GPL) and the 'GNU Lesser General Public
>>> License' (LGPL). libxml2 uses neithe
rsonally vote no. If the
interface was supposed to be portable to other backends, I'd probably
still vote no unless at least one other backend was included as proof of
concept. It would still be nice to have a Boost supplied backend,
probably via Spirit, but so long as I was confiden
Alexander Terekhov said:
> "William E. Kempf" wrote:
> [...]
>> >> > >> When and if the C++ standard adds true thread support, that
>> will
>> >> be, by default and in practice, the thread binding for C++;
>> >> whether the underl
Chuck Messenger said:
> William E. Kempf wrote:
>> I don't follow what you're code is supposed to be doing.
>
> Background: I have a structure of information, 'mythread', of which I
> need one per thread. That is, I've grouped all my tss variables into
ed on "certain", or "least", or
> "fastest" integers as optionally specified template argument) via
> atomic<> specializations ala numeric_limits<> ones.
This hardly suffices as documentation, or even a summary paper. I'd also
(as usual) take gr
27;s
difficult. If you can write a summary paper or even provide a base
implementation with thorough documentation, I'd definately be interested.
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
> Alexander Terekhov wrote:
>>
>> "William E. Kempf" wrote:
>> [...]
>> > >> How about moving this discussion to c.p.t.?
>> > >
>> > > Well, just in case...
>> >
>> > Thanks... I currently can'
> because mythread can't be deleted (for arcane reasons I won't get into
> here).
That depends. As long as you can set the value back to 0 before the
thread ends, you can still put this into thread_specific_ptr<>. Not a
universal solution, obviously, I
into that direction?
>
> I mean, the Boost.Thread library seems to be designed with
> safety in mind, but is still a little bit low-level.
>
> Are there any efforts to enhance the library further?
Yes.
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
ippet that you really don't
want this functor to be copied? If that's the case, you may want to make
use of boost::ref.
CTaskManager taskManager;
boost::thread_group mainThreadGroup;
mainThreadGroup.create_thread(boost::ref(taskManager));
mainThreadGroup.join_all();
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
to say, it happened
because I assumed Boost.Build was setting the warning level to an
appropriate default (i.e. the level that the IDE sets for new projects),
when in fact, it wasn't setting it at all. I posted about this a while
ago.
If this isn't the cause, then you'll have to
in theory, but I've never been comfortable living with it.
I know others do, but in my experience, especially with the MS compiler,
the highest warning level produces a LOT of meaningless diagnostics which
can be very difficult to eliminate... even with
requested during compilation.
This is generally done by compiling/linking against the multi-threaded
RTL.
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Douglas Paul Gregor said:
> On Thu, 27 Mar 2003, William E. Kempf wrote:
>> I'm using 0.20.4 (on Mandrake 9.1) and receive lots of errors. A few
>> examples:
>>
>> [ERROR] Error in column-width property value '33%':
>> org.apache.fop.fo.expr.Prope
(plus a lot of warnings). If you want a full log, I
can send it. A PDF is generated, but lands in
$BOOST_ROOT/doc/bin/gcc/debug/boost.pf. Shouldn't this be in
$BOOST_ROOT/doc/pdf or something similar? The produced PDF is viewable,
and looks pretty good from a casual glance.
--
W
Remy Blank said:
> On Thu, 27 Mar 2003 10:40:26 -0600 (CST), "William E. Kempf"
> <[EMAIL PROTECTED]> wrote:
>> Problems building:
>>
>> * On Mandrake 9.1 I had no issues.
>>
>> * On Cygwin, I get the result:
>>
>> xslt-xsltproc bin\
. After I get the Cygwin build working, I'll move on
to FOP and PDF generation and report other things I find.
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
David Brownell said:
> "William E. Kempf" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> Ahhh, the light bulb just went on, I finally understand. However, it
> does seem like this usage of TLS is a corner case, that is refactoring
> code to be t
answer to me!
To make this more concrete, TLS is most often used to make legacy
interfaces, such as the classic example of strtok, which maintain state
across calls, thread safe. That's what's being done in the hypothetical
"some_library_foo". TLS is really th
you
use Boost.Threads to create a thread that accesses MFC routines that use
TLS, you'll leak, because I elected to use _beginthread instead of
AfxBeginThread).
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
developers. Why should an application developer be forced to use
Boost.Threads just because library Foo choose to use Boost.Threads to make
the library thread safe?
This "solution" is fragile and difficult to manage today. Every time you
add yet another thread creation routine/proxy into the mix it gets
geometrically worse.
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Edward Diener said:
> William E. Kempf wrote:
>> David Brownell said:
>>> I am curious as to why the new version of the Thread library does not
>>> provide a static library in the 1.30 version of boost. After reading
>>> some initial posts, I have seen referen
Russell Hind said:
> William E. Kempf wrote:
>>
>> Theoretically at least, I don't see why this would cause a problem.
>> You intentionally leak, but the leak is benign since it occurs only
>> right before the application exits. But most users won't code
vc said:
>
> - Original Message -
> From: "William E. Kempf" <[EMAIL PROTECTED]>
>> > Doing so, the boost.thread will be build with the /MTd flag (for
>> debug). This is exactly
>> > what you said that it won't be a good idea, right? O
Peter Dimov said:
> William E. Kempf wrote:
>> Peter Dimov said:
>>>
>>> I agree with the suggestion. The default should be /W3 for VC 6, and
>>> /W4 (possibly with some specific warnings disabled) on VC 7+.
>>
>> Why /W4 for VC 7+? The IDE's
Peter Dimov said:
> William E. Kempf wrote:
>>
>> I guess I'm wondering if the official toolsets shouldn't be changed. I
>> don't understand why the MSDN indicates it should default to /W2 while
>> we're seeing it default to what I assume is /W1.
vc said:
>
> - Original Message -
> From: "William E. Kempf" <[EMAIL PROTECTED]>
>
>
>>
>> vc said:
>> >> As for the warnings themselves... I'm still doing more research
>> just to be 100% sure, but everything I've f
would
cause. So, unless you have some suggestion as to how I can enable this
usage with out causing confusion, I'm not sure I'd care to re-enable
static builds. But you could probably fairly easily hack things to build
that way yourself.
--
William E. Kempf
__
f (which won't work for threads created outside of
Boost.Threads) or with code in DllMain.
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Paul A. Bristow said:
> I was surprised to find that /Wp64 flag (detect 64-bit portability)
>
> means that std::size_t is 64 bit. This leds to a number of oddities
> that confused me. Is this perhaps causing your problem?
AFAIK and AFAICT, /Wp64 is not used.
--
Will
David Abrahams said:
> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>
>> David Abrahams said:
>>> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>>>
>>>> Hmm... this surprised me. Mr. Maclean indicated the warnings wer
David Abrahams said:
> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>
>> Hmm... this surprised me. Mr. Maclean indicated the warnings were
>> level 1 _and_ 2. Builds with bjam do report errors, so the warning
>> level can't be 0. MSDN indicates &q
st both RTLs, but that just makes testing more
difficult, while it's easy enough for users to specify the build variants
they prefer using the above.
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
#x27;m still doing more research just to be
100% sure, but everything I've found thus far indicates you can ignore
these warnings as long as you link against the same RTL in both the
Boost.Threads DLL and the application. After I verify this, I'll remove
these or do I need to manually set some
> option? I never got these warnings with Boost 1.29.
There does appear to be something wrong in your setup. I'm going to guess
that you're linking against the static RTL?
--
William E. Kempf
__
nce
with this, it may be a non-start suggestion, but I thought it would at
least be worth posting the link.
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
thing's actually added, however, maybe we should discuss things
a bit either here or on the Boost Install list.
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
release
probably won't work with this configuration, and I have to admit that I've
not tested this build variant in quite a while). Look at
$BOOST_ROOT/libs/thread/build/threads.jam to see how to do this.
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
a complex topic for which there's not
always hard and fast answers that everyone agrees on/likes. But if you've
got something, don't let that discourage you. I personally would
certainly like to see something along these lines in Boost.
--
William E. Kempf
So maybe the
http://www.cvsgui.org link has just not been fixed since then? Someone
with more info on this will have to decide if the Boost web page needs
updating, but in the mean time you should be able to get any of the GUI
clients you'
hink it would be much better if RPM are
> "officially" available (i.e from sourceforge download page).
>
> Lastly, this issue is not release show-stopper: the *spec file which
> creates RPM is not in Boost CVS tree. Malte can make the changes when
> 1.30 is out.
Should
plementation only for
> all libraries?
This has been discussed before. The switch is a Boost.Threads switch
only, and not something that all Boost libraries are doing. It was done
to simplify the build process, since Win32 requires the use of a DLL for
TLS cleanup any way.
--
W
lease, however.
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Geurt Vos said:
>
> Just downloaded the 1.30.0-beta1 zip. There boost/thread.hpp
> is slightly wrong. Line 16 reads:
>
> #include
>
> but should be:
>
> #include
Fixed. Thanks.
--
William E. Kempf
___
Unsubs
Noel Yap said:
> Just wondering, looking at boost/thread/once.hpp, I see that once_flag
> is typedef'd to long, why not bool or char to take up less memory?
For compatibility with the underlying system APIs.
--
William E. Kempf
___
o to, that's part of the
reason why I didn't give one. However, the one you have will probably
suffice?
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Edward Diener said:
> William E. Kempf wrote:
>> Edward Diener said:
>>> William E. Kempf wrote:
>>> I still don't think it is a TLS issue but rather a thread cleanup
>>> issue and the restrictions imposed by MS's design of that situation.
>>&
Edward Diener said:
> William E. Kempf wrote:
>> Edward Diener said:
>>> William E. Kempf wrote:
>>>> And it's full of issues.
>>>> You are quite limited in what you can safely do within DllMain. Any
>>>> calls to synchronization routin
gt;
> Sleep(1);
> }
> }
>
> (I don't actually use yield yet, so currently have no preference for
> either, but just wondered what the intended use of yield was)
I'll look into this and fix it. Thanks.
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Edward Diener said:
> William E. Kempf wrote:
>>> You can clean up your own TLS index ( or indices ) in your DllMain
>>> routine when the seond parameter is DLL_PROCESS_DETACH, meaning that
>>> your process is being exited. AFAIK this is the standard way to do
>&
Edward Diener said:
> "William E. Kempf" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>>
>> Edward Diener said:
>> > "Alexander Terekhov" <[EMAIL PROTECTED]> wrote in message
>> > news:[EMAIL PROTECTED]
&
; only those cases in which the DLL is not dynamically loaded, which is
> the vast majority of cases. Of course to make TLS completely foolproof,
> one does not use __declspec(thread) but instead one uses the Win32 TLS
> API functions instead.
Where you run into issues with TLS clea
libraries not being thread safe (and
I've not had the time to get STLPort to work with the Cygwin/-mno-cygwin
combination that I use). The specific problem you're describing is not
one I've seen, so I'll look into it shortly, but don't be too quick to
assume it's not
w
>> what they did.
>
> Are you kidding? Python users (almost) never read docs!
> {sorry all you other Python users out there; it's just my impression}.
No? I thought this sort of thing was done all the time:
>>> import os
>>> help(os)
>>> help(os
crunch
time, like Beman and others have pointed out, you'll not get that kind of
feedback, pro or con, at this point in time.
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Beman Dawes said:
> At 11:56 AM 2/18/2003, William E. Kempf wrote:
>
> >Well, I'm in favor of that, since we're moving at least some of the
> documentation to Boost.Book with this release (or so I gathered). So
> what's the group opinion on this one?
>
>
Thread
creation works portably? You'll still wind up "reinventing the wheel"
here, you're just choosing to implement thread creation instead of the
mutex and TSS. From my POV it would be easier to do the mutex and TSS,
but hey, I don't care as long as you can prove that the testing framework
works *before* I start using it to test Boost.Threads.
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
till exists
>> in the current version of condition.cpp for notify_all
>> (win32)--not all control paths will release the mutex.
>> Am I mistaken, or is this a bug?
>
> It looks the same to me. Any comment about this?
I somehow missed the original post here. Now fixed in CVS
Douglas Paul Gregor said:
> On Tue, 18 Feb 2003, William E. Kempf wrote:
>> Douglas Gregor said:
>> A reasonable concern. But if we keep only release versions of
>> generated documentation in CVS, I don't think it will be too severe.
>> Intermediate doc changes
t,
but Boost.Test is also being used outside of the Boost project, and I
won't begin to claim that I know they don't need thread-safe versions).
As for not doing it in a hurry... I understand what you're saying, but
this sounds like it jeapordizes this and future release sch
nvinced that Boost.Book is a good idea long term.
We just need to try and impact the whole project as minimally as we can
for the short term.
> There's an unfortunate Catch-22 with all this: to smooth the BoostBook
> learning curve would require further integration with the Boost CVS
> repository (not the sandbox), but we shouldn't integrate with Boost CVS
> until BoostBook has been "accepted" (whatever that means for a tool).
> But "acceptance" requires, at the very least, more developers to hop
> over the initial hump and to start seeing the benefits of BoostBook.
I think there's several of us interested who will be working on this when
time permits. But honestly, having it in the sandbox is at least a little
inconvenient... and to me it makes little sense if some released
documentation is going to depend on it.
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
it is so
> critical, that we need to hurry to fix it for this release. My plan was
> to address it after CLA. I still hope to be able to use Boost.Thread for
> this. I will try to address 1(without tss) 2 and 4 today.
Thread safety issues are very critical, AFAICT. Boost.Threads depends on
Boost.Test, and assumes it is thread safe.
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
> Hangs on both GCC 2.95.3 and 3.2:
>
> test / errors_handling_test...
>
>http://boost.sourceforge.net/regression-logs/cs-OpenBSD-links.html#errors_handling_test%20gcc
>
>http://boost.sourceforge.net/regression-logs/cs-OpenBSD-links.html#errors_handling_test%20gcc-3.2
T
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
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 in
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
&g
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
>>
> 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
&g
future res(function);
executor(res);
return res;
}
template
void thread_executor(F function)
{
thread thrd(function);
}
future res = execute(foo, &thread_executor);
double d = res.result();
(And yes, I would offer these interfaces as well.)
Thoughts?
William E. Kempf
[EMAIL PROTECTED]
>
> 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:
> >>
7;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 until the call has
> > completed or to simply document this as undefined behavior.
>
> Yes, good point, I missed that.
I lean towards simple undefined behavior. How do you feel about it?
William E. Kempf
[EMAIL PROTECTED]
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
> 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:
>
1 - 100 of 233 matches
Mail list logo
