implementation could in both cases
return true (or false) and thus
could lead to two successive trials to lock the same mutex, which would
lead to an lock exception.
You're correct, and the solution is simply to replace the operator with
std::less calls.
--
William E. Kempf
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't aware,
that you provide total ordering on mutexes). Otherwise I
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_specific_ptr. BTW, you still have to remember that the
functor is copied, and data passed
.
--
William E. Kempf
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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
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
::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
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 it will be a pointer
to a _copy_ of the functor?
Because
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
trivial to implement portably with the current
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
considered part of the thread in any event
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 stopwatch
{
public:
stopwatch()
: started_(::GetTickCount
with distributions and have the individual file licenses refer to
this distributed license?
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
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
runtime-linkstatic/dynamic, the library is still generated as a
DLL. I do not exactly know what is meant
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 huge archive. Could you remember roughly
, however. It should also be fairly trivial.
--
William E. Kempf
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-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
___
Unsubscribe other
soon. Ignore them for now.
--
William E. Kempf
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
the warnings because this change also effects how you link
against the C RTL. When you tried to compile the project with no MFC you
got the error you did because you failed to compile against a
multi-threaded C RTL. All dependencies in Boost.Threads are with the C
RTL and not MFC.
--
William E
have to agree with
Dave. You should learn the command line long before using any GUI,
especially one with only a thin wrapper like WinCVS. It's an easier
learning curve on a very complex tool.
--
William E. Kempf
___
Unsubscribe other changes: http
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
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 race condition. It also occurs when extracting data from
the queue. Whether
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 could write non-safe code that presents a race
backend,
probably via Spirit, but so long as I was confident that I was not tied to
any specific non-Boost library, it wouldn't matter that much.
--
William E. Kempf
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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 neither, and its license is fully
compatible with boost's license requirements
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 backends for proof of concept.
Fair enough
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 implementation method
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 with MS-interlocked API. For example, for
DCSI and DCCI things, all you
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
it may help
with your current use case.
It would be nice if there were a version of thread_specific_ptr
which didn't delete, e.g.:
thread_specific_ptrmythread, non_deleting current_thread;
Just a suggestion...
Already in the thread_dev branch.
--
William E. Kempf
wrote:
William E. Kempf wrote:
[...]
How about moving this discussion to c.p.t.?
Well, just in case... Forward Quoted
Thanks... I currently can't access c.p.t. in any reasonable manner.
I'm working to rectify this,
http://news.cis.dfn.de might help
for in that release. I'm
trying to track the efforts you've been doing in this area, but you
scatter things so much with see this link type posts that it'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
for the above, including preconditions,
postconditions, etc. for each method? I'll get by if you can't, but
documentation would be very useful.
--
William E. Kempf
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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 a
single structure. I need to bootstrap
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 underlying thread environment is POSIX, Win32, or
something else. This is great, as long
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
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 ask individual authors,
and/or submit patches.
--
William E. Kempf
::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
a LOT of meaningless diagnostics which
can be very difficult to eliminate... even with pragmas. As a best
practice suggestion, it's a great idea... as a requirement, I'd have to
voice an opinion against.
--
William E. Kempf
___
Unsubscribe other changes
.
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
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 thread safe. I can see how this could
E. Kempf
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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\gcc\debug\boost.docbook
'XML_CATALOG_FILES' is not recognized as an internal
this be in
$BOOST_ROOT/doc/pdf or something similar? The produced PDF is viewable,
and looks pretty good from a casual glance.
--
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.PropertyException: No conversion defined
[ERROR] property
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.
--
William E. Kempf
created outside of
Boost.Threads) or with code in DllMain.
--
William E. Kempf
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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 found thus far indicates
you can ignore these warnings as long as you link against the same
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. But, projects
created by the IDE default to /W3 (which
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 default is still /W3 on these
compilers. I don't think selecting
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? Or am I missing
something here?
Sorry, I guess I wasn't very clear
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 this
way, nor do I want to have to deal
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 references to thread local storage,
but haven't seen
routine/proxy into the mix it gets
geometrically worse.
--
William E. Kempf
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
solution here (other than
changing the legacy interface, which often isn't an option), which is why
I said telling them not to use thread_specific_ptr is the same as telling
them not to use Boost.Threads.
--
William E. Kempf
___
Unsubscribe other changes
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
___
Unsubscribe other changes: http
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 were
level 1 _and_ 2. Builds with bjam do report errors, so the warning
level can't be 0. MSDN
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
(at least with this version... the next 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
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
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're looking for from http://www.wincvs.org.
--
William E. Kempf
___
Unsubscribe other
done on that front. I only ever intended to be a
moderator in this case, because of time constraints, but someone needs to
take a much more active role in ensuring this area is addressed!)
--
William E. Kempf
___
Unsubscribe other changes: http
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.
--
William E. Kempf
Geurt Vos said:
Just downloaded the 1.30.0-beta1 zip. There boost/thread.hpp
is slightly wrong. Line 16 reads:
#include boost/thread/conditin.hpp
but should be:
#include boost/thread/condition.hpp
Fixed. Thanks.
--
William E. Kempf
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
___
Unsubscribe other
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.
So I can well understand your chagrin at the tricks you must do
?
--
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
this.
(Note: The issue is more
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 routines is likely to deadlock the entire
process.
I agree that this is so. You
will agree that the MS TLS
implementation has serious design issues which need to be corrected.
--
William E. Kempf
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-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 a fault in Boost.Threads. If anyone can help in solving
these portability issues, I'd appreciate it.
--
William E. Kempf
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?
I'd like to hold off as many changes as possible
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.path)
I know I do it a lot.
--
William E. Kempf
___
Unsubscribe other changes: http://lists.boost.org/mailman
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
in the testing framework,
it's even more difficult.
--
William E. Kempf
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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 would either have to be accessed directly
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.
--
William E. Kempf
___
Unsubscribe other changes: http://lists.boost.org
Boost.Threads.
--
William E. Kempf
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
.
--
William E. Kempf
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
...
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
Thanks. I'll try to look into this tomorrow.
--
William E. Kempf
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
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
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
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
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
can't just call any function here.
--
William E. Kempf
[EMAIL PROTECTED]
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
constructor in the new design, since it's Copyable and Assignable. If
there's reasons to do this, we can now switch to a self() method for
accessing the current thread.
--
William E. Kempf
[EMAIL PROTECTED]
___
Unsubscribe other changes: http
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
. Sometimes you don't care, but often you do.
And for those cases you have a low-level interface, right?
Where's the low level interface if I don't provide it? ;)
--
William E. Kempf
[EMAIL PROTECTED]
___
Unsubscribe other changes: http
be opposed to another class, however, as I don't
think that solves anything, but instead makes things worse.
--
William E. Kempf
[EMAIL PROTECTED]
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
careful thought about the FULL example you
posted to understand this.
--
William E. Kempf
[EMAIL PROTECTED]
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
that will satisfy all concerns, however, that's not been given yet.
--
William E. Kempf
[EMAIL PROTECTED]
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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
that simply should never happen unless
there's a bug in the Boost.Threads library. (That said, it's possible
I've missed some error conditions that should be exceptions, especially on
the Win32 platforms where error conditions aren't documented.)
--
William E. Kempf
[EMAIL PROTECTED
.
I would be most happy if we could cooperate and join efforts.
Certainly.
--
William E. Kempf
[EMAIL PROTECTED]
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Wednesday, February 05, 2003 3:04 PM [GMT+1=CET],
William E. Kempf [EMAIL PROTECTED] wrote:
What I would like to see is a new boost::thread implementation
which meets the following requirements.
a. There shall be two interfaces to a thread. One for creation of a
thread, from
patch, that works both before and after a
Solaris upgrade (i.e. let's not have extra code when it's not needed), and
I'll apply it to the library.
--
William E. Kempf
[EMAIL PROTECTED]
___
Unsubscribe other changes: http://lists.boost.org/mailman
in our testing tools in the future.
William E. Kempf
[EMAIL PROTECTED]
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
interesting solution is to use a thunk, much like is done in
ATL. This technique could be trivially used to invoke functors.
William E. Kempf
[EMAIL PROTECTED]
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
1 - 100 of 173 matches
Mail list logo
