Smith, Devin wrote:
* Why is the new license better?
A: Because it's more thorough
CPL is even more thorough. Heck, what about patents? What about
re-licensing/forks (e.g. infamous LGPL - GPL degradation)?
regards,
alexander.
--
If Unix were a car, they said, SCO Unix was like a
Peter Dimov wrote:
[...]
It's not that simple. Whether something is a programming error is determined
by the library's specification, not vice versa. In other words, under the
current specification, re-locking a locked lock :-) is not an error, as it
is well defined. It is not a just an
Daniel Frey wrote:
[...]
PS: Note that there's also a difference between the standard theretical
world or portable, well defined behaviour and the real world. I am
explicitly talking about the real world! Boost is not an academic
excercise. At least I hope so... :o)
In the real world you
Howard Hinnant wrote:
[...]
class rw_mutex
{
public:
typedef detail::read_lockrw_mutex read_lock;
typedef detail::write_lockrw_mutex write_lock;
...
};
[...]
This looks slightly more readable and writable to me. And will avoid
unlock() having to check what kind of
David Abrahams wrote:
[...]
Now the disclaimer. I am not sure to what extent we are even
supposed to discuss such legal matters here; the public archives of
the mailing list can be used as evidence in a hypothetical future
lawsuit (SCO showed the way). So I won't go into details.
Heh.
David Abrahams wrote:
Alexander Terekhov [EMAIL PROTECTED] writes:
P.S. CPL == *WIN*-*WIN*
These legal issues are sufficiently confusing to overwhelm the brains
of most of us regular Boost people.
Uhmm. Your previous posting was not bad at all
Glen Knowles wrote:
[...]
The Common Public License already has a section in the wiki and fails
the boost requirements as shown.
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost_License/Common_Public_License
Yeah. That review process was really entertaining. Thanks for the
David Abrahams wrote:
[... P.S./P.P.S./P.P.P.S./P.P.P.P.S. ...]
Thanks for the information. I've bookmarked everything.
regards,
alexander.
P.S. Please don't infringe upon my concepts and methods.
We can struck a licensing deal, of course.
___
Ross Smith wrote:
On Wednesday 9 July 2003 05:48, Alexander Terekhov wrote:
Common Public License
The CPL is incompatible with the GPL.
Translation: RMS just hates patents. (and DMCA, of course)
http://finance.messages.yahoo.com/bbs?board=1600684464tid=caldsid=1600684464action=mmid
Peter Dimov wrote:
[...]
The answers to questions 12 and 18 from
http://www-106.ibm.com/developerworks/library/os-cplfaq.html
seem problematic.
Well,
http://ntxshape.sourceforge.net/opensource.html
WRT q12:
quote
The Lesser GPL used to be called the Library GPL. For historical
David Abrahams wrote:
[...]
As for Must not require that the source code be available for
execution or other binary uses of the library... well, what's the
problem? www.boost.org was pretty stable, thus far.
The problem is that we don't want to force companies to assume the
risk that
Glen Knowles wrote:
[...]
Now you're arguing that the boost license requirements should be
changed in order to make them compatible with the CPL? That's a bit of
a stretch, especially since I like the boost requirements as they are.
Frankly, I think that boost requirements make no sense. As
Jon Biggar wrote:
[...]
There is actually one case that needs a semaphore that has no reasonable
alternative in pthreads. The only pthread synchronization operation
that is asynch-reentrant safe (i.e. can be called from a signal handler)
is signaling a pthread semaphore.
There's no such
Maxim Egorushkin wrote:
[...]
Seems like the issue is undefined behaviour when casting away volatile.
Do I get it right?
Yes, UB is the issue (one of the most obvious tips of the iceberg).
Well, more on volatiles (low level stuff) can be found below. Uhmm,
as for higher level safety (and
Maxim Egorushkin wrote:
Alexander Terekhov [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Maxim Egorushkin wrote:
[... ala Alexandrescu volatiles ...]
http://groups.google.com/groups?threadm=3EE84807.DD00F4D0%40web.de
http://groups.google.com/groups?threadm
Paul A. Bristow wrote:
[...]
May I suggest consideration of what happens in a decade or two when boost.org
might not longer exist to provide a reference, but we still need to ensure that
the license terms are still available.
version 1.2.8
Since code is being used from Open Source for snip, IP legal at snip
requires that our team to complete additional steps in order for OSSC to
approve COO. OSSC reviewed the COO and had pedigree concern based on
FIFOReadWriteLock.java by Alexander Terekhov. I searched the header file
James Curran wrote:
Alexander Terekhov wrote:
IANALBIPOOTN.
um... I Am Not A Lawyer But I Play One On ...
The Net.
regards,
alexander.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Maxim Egorushkin wrote:
Alexander Terekhov [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Maxim Egorushkin wrote:
Alexander Terekhov [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Maxim Egorushkin wrote:
[... ala Alexandrescu volatiles
Ed Brey wrote:
[...]
In the use case I am asking about, which is typical for shrink-wrap
software, only the libraries are pre-existing. The main program,
the help files, and the read-me file are all brand new and they are
all created together and are used together. It would be seem
Maxim Egorushkin wrote:
[... ala Alexandrescu volatiles ...]
http://groups.google.com/groups?threadm=3EE84807.DD00F4D0%40web.de
http://groups.google.com/groups?threadm=3EE861E5.13B60F31%40web.de
(Subject: Re: volatile keyword usage philosophy (long!))
regards,
alexander.
Fernando Cacciola wrote:
[...]
Motivated by A. Terekhov concerns, I think the license should, if at all
possible, expressely PROHIBIT anyone, including the copyright holder,
from patenting the covered Software and any implied intellectual production.
That would make no
Beman Dawes wrote:
[...]
// See accompanying license for terms and conditions of use.
http://www.eclipse.org/eclipse/eclipse-charter.html
Licensing
All contributions to the Eclipse Project must adhere to the Common
Public License http://www.eclipse.org/legal/cpl-v10.html.
Peter Dimov wrote:
Ed Brey wrote:
Peter Dimov wrote:
I'd like also to point out that it seems to me that the old in all
copies form is better than the new one; the legal system is
sufficiently flexible
to reliably recognize a copy (i.e. a password protected RAR archive
of an mp3
Fernando Cacciola wrote:
[...]
Motivated by A. Terekhov concerns, I think the license should, if at all
possible, expressely PROHIBIT anyone, including the copyright holder,
from patenting the covered Software and any implied intellectual production.
That would make no sense. My concern is
Howard Hinnant wrote:
[...]
Will the copyright need to appear in the standard itself?
Uhmm, why would you care?
My job is to implement the std::lib for Metrowerks. Why would I /not/
care?
Because it has no bearing whatsoever on you job. ?
regards,
alexander.
--
Beman Dawes wrote:
[...]
The point of the Boost license is to grant various permissions to everyday
users. Special uses such as ISO standardization, or maybe some corporation
that wants a different license, can be dealt with on a case-by-case basis.
That's a nice aspect of the developer
Fernando Cacciola wrote:
Alexander Terekhov [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Fernando Cacciola wrote:
[...]
Motivated by A. Terekhov concerns, I think the license should, if at all
possible, expressely PROHIBIT anyone, including the copyright holder
Beman Dawes wrote:
At 10:27 PM 6/26/2003, Howard Hinnant wrote:
[...]
company, and then moved to another company. Although no physical copy of
the source code was involved, the programmer had a good memory, and
basically just duplicated the prior effort.
Yup. That's what The Clean Room is
David Abrahams wrote:
Thomas Wenisch [EMAIL PROTECTED] writes:
I have been told by previous employers' lawyers that the word Copyright
is in fact required.
That matches my understanding. Also that (C) has no legal value.
http://www.iusmentis.com/copyright/crashcourse/requirements
Beman Dawes wrote:
At 01:50 PM 6/25/2003, Alexander Terekhov wrote:
Beman Dawes wrote:
[...]
* Boosters (or their lawyers) from countries other than the US; do they
spot any issues missed by Boost's US-centric legal team?
They seem to have missed a whole bunch of issues
David Abrahams wrote:
[...]
Nothing is legally bullet-proof. People should not have illusions
about that.
Well, I'd say that opinions (dissents aside) issues by
panels like http://www.supremecourtus.gov (and alike) are
pretty bullet-proof. Oder? ;-)
regards,
alexander.
--
SCO to sue Al
Matt Hurd wrote:
[...]
PS: does #include boost/any_old_header.hpp make you a derived work?
I'd say that in the context of new boost license, derivative work is
a work that includes some {transformed} copyrighted expressions of ideas
such that the result would constitute an infringement if
Beman Dawes wrote:
[...]
You really need to talk to IBM's lawyers to get their views. I know they
have looked at the current Boost licenses, because they were kind enough to
report some ambiguous wording, but I have no idea what else they may be
concerned about.
I'm pretty sure that IBM's
Howard Hinnant wrote:
Since boost is a spring board for standardization of a library, I'm
wondering if the boost license requires the copyright notice to follow
for other implementations which follow the interface of the boost
library, but independently develop the implementation?
In
Beman Dawes wrote:
[...]
* Boosters (or their lawyers) from countries other than the US; do they
spot any issues missed by Boost's US-centric legal team?
They seem to have missed a whole bunch of issues surrounding implied
patent license.
regards,
alexander.
Matt Hurd wrote:
The author of a derivative work can put in a more restrictive license
right? In this case, wording that gives the full Boost permission must
still be included according to the draft license.
This would lead to a license text like:
snip
I am a little confused. Like
Victor A. Wagner, Jr. wrote:
well, unless (likely given this biz) the words have changed meaning again,
naked semaphore was described by Dijkstra way back when (1964??)
http://www.cs.utexas.edu/users/EWD/index01xx.html
But just a few years later (in 1971) Sir Tony Hoare (ironically, his
Stefan Seefeld wrote:
Alexander Terekhov wrote:
Show me some code. I mean something that shows why do you need counting
semas.
I'm using a bounded task queue (with the producer/consumer pattern),
where the queue is implemented with std::queue, a mutex, and two semaphores.
One
Maciej Sobczak wrote:
Hi,
Alexander Terekhov wrote:
Show me some code. I mean something that shows why do you need counting
semas.
This wording is too strong. Going this way, we can *always* say that
feature X is not deadly needed and can be replaced by two or more
(probably
Stefan Seefeld wrote:
Alexander Terekhov wrote:
I see that you're also not fond of following the links. Okay.
that's starting to get annoying...
Yeah. My wife also says that this is something I do best. ;-)
I did follow the links, I just don't happen to agree with what
was said
Stefan Seefeld wrote:
[...]
And then there is the other semaphore I use to count the free slots,
which you didn't comment on, probably because it didn't fit into your
arguments...
No, actually, it strengthens the argument, because you now have even more
state that needs to be
Maciej Sobczak wrote:
[...]
What about providing both (condvars and semas), but with documenting
known pros and cons?
Personally, I'd have no problems with some *separate* Boost.Semas (for
things meant to be done by the current POSIX/IPC semaphores: async-
signal-safe unlock operation,
Victor A. Wagner, Jr. wrote:
I'm baffled that they want to penalize (time and space) those for whom a
naked semaphore works. It's blatantly clear to anyone who's had to write a
mutex that it's additional code on TOP of a semaphore.
Optimization stratergies aside (they are different for
Victor A. Wagner, Jr. wrote:
I'm baffled that they want to penalize (time and space) those for whom a
naked semaphore works.
Show me please an example illustrating naked semaphore in work.
It's blatantly clear to anyone who's had to write a
mutex that it's
Stefan Seefeld wrote:
[...]
But binary semaphore are only a (small) subclass of semaphores, and I'd
use semaphores mostly to represent value *and* lock, where the value's
domain is larger than just 1/0.
Show me some code. I mean something that shows why do you need counting
semas.
regards,
David Abrahams wrote:
Alexander Terekhov [EMAIL PROTECTED] writes:
Okay. But fix the http://www.boost.org/more/error_handling.html;, please.
I don't think there's anything to be fixed, but if you post a patch
I'll happily consider it.
Yeah. open source.
FYI, Forward-Inline
David Abrahams wrote:
Alexander Terekhov [EMAIL PROTECTED] writes:
Terje Slettebø wrote in message [EMAIL PROTECTED]:
[...]
why shouldn't std::exception use std::strings?
See here (http://www.boost.org/more/error_handling.html).
Unfortunately, operating systems other
Terje Slettebø wrote:
From: Alexander Terekhov [EMAIL PROTECTED]
Terje Slettebø wrote in message [EMAIL PROTECTED]:
why shouldn't std::exception use std::strings?
See here (http://www.boost.org/more
Terje Slettebø wrote in message [EMAIL PROTECTED]:
[...]
why shouldn't std::exception use std::strings?
See here (http://www.boost.org/more/error_handling.html).
Unfortunately, operating systems other than Windows also wind non-C++
exceptions (such as thread cancellation) into the
Stefan Seefeld wrote:
hi there,
I'v been trying to find some info as to why semaphores
are considered harmful by the boost::thread authors,
without luck. Is there any concise text describing
the problem ?
Well,
http://www.boost.org/libs/thread/doc/faq.html#question10
I'v been using
Stefan Seefeld wrote:
[...]
I'm still not convinced.
http://google.com/groups?selm=3CED3306.DF6DB829%40web.de
(Subject: Re: many semaphores)
regards,
alexander.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Nicolas Fleury wrote:
[...]
http://google.com/groups?selm=3CED3306.DF6DB829%40web.de
(Subject: Re: many semaphores)
Would it be possible to post some code that experience has shown to be
error-prone using semaphores comparing with conditions/mutexes?
Sure... thanks to the Microsoft
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 need is hoist-load and
Nicolas Fleury wrote:
Alexander Terekhov wrote:
Nicolas Fleury wrote:
[...]
Would it be possible to post some code that experience has shown to be
error-prone using semaphores comparing with conditions/mutexes?
Sure... thanks to the Microsoft Corp.
http://msdn.microsoft.com
Nicolas Fleury wrote:
[...]
It is showing that semas (e.g. bin-semas aka auto-reset events)
are really error-prone. Their implementation of counting semaphore
How?
Review the code. You'll see that it has many problems. One problem
is precisely the thing that POSIX rationale is talking
Nicolas Fleury wrote:
[...]
What is the paper you have in mind to justify the absence of semaphores?
I would like very much to understand and be convinced. It would also
be nice if the #10 of the FAQ would point to this paper.
It can be found here:
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 as it doesn't do or say
Alexander Terekhov wrote:
Russell Hind wrote:
Trevor Taylor wrote:
Who? Me?
I think Peter meant Alexander
I got the message. I'll post refcountthread_safety,
typename integer_t once I'll have some time for it. It won't include
atomic implementation(s), however. ;-)
http
Forward Inline
Original Message
Message-ID: [EMAIL PROTECTED]
Newsgroups: comp.lang.c++.moderated
Subject: Re: OO design: Is errno Exception?
References: ... [EMAIL PROTECTED]
Early Ehlinger wrote:
Alexander Terekhov [EMAIL PROTECTED] wrote:
Early Ehlinger wrote
Russell Hind wrote:
Trevor Taylor wrote:
Who? Me?
I think Peter meant Alexander
I got the message. I'll post refcountthread_safety,
typename integer_t once I'll have some time for it. It won't include
atomic implementation(s), however. ;-)
regards,
alexander.
Alexander Terekhov 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
Forward Inline
Original Message
Message-ID: [EMAIL PROTECTED]
Date: Thu, 22 May 2003 19:37:13 +0200
From: Alexander Terekhov [EMAIL PROTECTED]
Newsgroups: comp.programming.threads
Subject: shared_ptr/weak_ptr and thread-safety
References: ... [EMAIL PROTECTED]
Joseph Seigh
Forward Quoted
Joseph Seigh wrote:
Alexander Terekhov wrote:
Joseph Seigh wrote:
Well, Detlefs calls it lock-free reference counting. But Boost
would probably call what they're doing with thread-safe reference
counting lock-free also, and they are not the same.
They don't
Forward Inline
Joseph Seigh wrote:
Alexander Terekhov wrote:
Joseph Seigh wrote:
Well, Detlefs calls it lock-free reference counting. But Boost
would probably call what they're doing with thread-safe reference
counting lock-free also, and they are not the same.
They don't
Kevin Atkinson wrote:
This is a repost of my Lock Classes. Hopefully this time I will get some
constructive feedback. These classes have the following features.
1) The ability to acquire a lock and release it when the object
goes out of scope effectively implemented the Monitor
Rozental, Gennadiy wrote:
[... 1-6 ...]
So. Do we still want to fight about best name for non existent component?
We don't. The BEST name (number 7 -- what else would you expect from such
magic number) is:
wrap/wrapper
of course. ;-)
regards,
alexander.
Rozental, Gennadiy wrote:
wrap/wrapper
This is another name for the proxy.
Nah, proxy is wrapper's implementation detail. ;-)
http://www.research.att.com/~bs/wrapper.pdf
regards,
alexander.
___
Unsubscribe other changes:
Edward Diener wrote:
[...]
DllMain's DLL_THREAD_DETACH is a better design, I think you must realize
that you are dealing with a company with millions and millions of developers
Yeah. zillions of innocent programmers. http://tinyurl.com/6hlt
regards,
alexander. former MSDN-universal
Ken Hagan wrote:
Alexander Terekhov wrote:
Uhmm. In return, I venture to suggest that MS-TLS can and shall be
characterized as ``utterly busted.''
Fine, but the OP asked about existing practice and the bugs
don't change the fact that k can be a template parameter
if the compiler
William E. Kempf wrote:
[...]
explicit scoped_lock(lightweight_mutex m): m_(m)
{
while( InterlockedExchange(m_.l_, 1) )
{
// Note: changed to Sleep(1) from Sleep(0).
// According to MSDN, Sleep(0) will
Ken Hagan wrote:
Alexander Terekhov wrote:
I, for one, believe strongly that k is nothing but
static_casttypeof(k)*(pthread_getspecific(__k_key));
It *isn't* a compile-time constant (just like errno isn't a compile
time constant).
MSVC has no pthread_getspecific(), so I
David Abrahams wrote:
Gabriel Dos Reis [EMAIL PROTECTED] writes:
David Abrahams [EMAIL PROTECTED] writes:
| I disagree with your conclusion. As I've said elsewhere, k can be a
| compile-time constant in the same way that X::k is a compile-time
| constant.
Certainly, you've
Peter Dimov wrote:
[...]
What makes you think that statically initializing a mutex is faster? It only
defers the initialization until the first lock call occurs.
That's the way how it works under win32. ;-)
Plus, pthread_mutex_init gives you the option to test for errors, should you
decide
Kevin Atkinson wrote:
On Wed, 19 Feb 2003, Alexander Terekhov wrote:
struct pthread_mutex_t_ {
/* ... */
#ifdef __cplusplus
__copy_ctor(const pthread_mutex_t_) {
throw Don't do this!;
}
#endif
};
typedef struct pthread_mutex_t_
Ken Hagan wrote:
Alexander Terekhov wrote:
Ken Hagan wrote:
[...]
3a If we allow Ck [...] It is then possible to initialise static
variables [...] and the results depend on the thread that ran
first. Again, we have the same problem passing a pointer to
a function, so I'm
Kevin Atkinson wrote:
[...]
I have got very little indication that you actually looked at what my
classes are offering.
Uhmm. Original-To aside, your Mutex class offers undefined behavior;
you really can NOT replicate a {pthread_mutex_t} mutex. I'm not sure
about the rest of your classes,
Kevin Atkinson wrote:
On Wed, 19 Feb 2003, Alexander Terekhov wrote:
Kevin Atkinson wrote:
I have got very little indication that you actually looked at what my
^^^
classes are offering.
Uhmm. Original-To aside,
What does
Peter Dimov wrote:
[...]
I must admit that I didn't expect even for p to be different across threads.
Not doing so would probably violate a rather nice axiom stated
in the 1.7/1. ``Every byte has a unique address.'' ;-) Seriously,
TLS shall not be private; similar to automatic storage
Kevin Atkinson wrote:
On Wed, 19 Feb 2003, Alexander Terekhov wrote:
Kevin Atkinson wrote:
static const pthread_mutex_t MUTEX_INIT = PTHREAD_MUTEX_INITIALIZER;
class Mutex {
pthread_mutex_t l_;
public:
Mutex() : l_(MUTEX_INIT
Greg Colvin wrote:
Any thoughts on this issue?
My thoughts:
a) *errno* (the C99/POSIX.1-2001/SUSv3 edition of it).
b) *lazy* is good.
Well,
http://groups.google.com/groups?selm=3DA6C62A.AB8FF3D3%40web.de
(Subject: Re: local statics and TLS objects)
Fernando Cacciola (Home) wrote:
Kevin, we're currently in the middle of a release and a formal review...
If you wait a week or so.. and recall our attention, you're likely to get a
response.
Just hold on.
And, in the meantime, you might want to post your stuff to:
Alexander Terekhov wrote:
Pavel Vasiliev wrote:
[...]
pthread_refcount_decrement() // with msync for proper mut.obj-cleanup
Basically [in terms of proposed/revised Java MM], it's VOLATILE-RELEASE
when count 1 'prior to decrement' and VOLATILE-ACQUIRE when the count
drops to 0
and deletion details)
with Zombies, resurrection [God rules], etceteras.
And, BTW, Forward Inline
Original Message
Newsgroups: comp.programming.threads
Subject: Re: threadsafe reference counting
Alexander Terekhov wrote:
kinda pthread_refcount_t-SKETCHv3
Here's
Peter Dimov wrote:
Alexander Terekhov wrote:
[...]
bool acquire_strong_from_weak() {
int status = pthread_refcount_enroll_one(strong_count); //
[...]
Or am I just missing and/or misunderstanding something?
You are missing the fact that nobody (even Google) has a clue
Pavel Vasiliev wrote:
[...]
Thread A, in release_strong:
atomic_decrement(strong_count) == 0,
enter strong_refs_lost(),
lock
ACK.
Thread B, in acquire_strong_from_weak:
NAK.
Thread B, in release_weak:
atomic_decrement(weak_count) == 0,
Thread A, in
Pavel Vasiliev wrote:
Alexander Terekhov wrote:
[...]
Pavel Vasiliev wrote:
The true locking/unlocking, not InterlockedIncrement/Decrement()
Nah, pthread_refcount_t. ;-)
even if availabe, is necessary
repost [with repaired link]
Peter Dimov wrote:
[...]
Another alternative might allow all of the following:
async_callint f(create_thread(), bind(g,1,2));
int r = f();
async_callint f(thread_pool(), bind(g,1,2));
int r = f();
Using an undefined-yet Executor
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/boost
Pavel Vasiliev wrote:
[...]
I really think that having the only mutex for all short smart
pointer-related interlocked operations will not harm performance of
real-life applications in mp systems. In my code this mutex is used
only for really short operations like lock, increment, save to
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).
Unimportant, IMO.
David B. Held wrote:
Pavel Vasiliev [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
[...]
In my implementation of refc_ptr operator= performs
incrementing/decrementing within a single guarded section (since
the only global instance of interl. op. mutex
Wolfgang Bangerth wrote:
[...]
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
Shimshon Duvdevan wrote:
[...]
So, if upgrading Solaris is not an option, I should patch boost.threads each
time a new version is out? Isn't it easier to add a couple of #ifdefs? :)
I'd suggest that you should just wait for a new version that
would hopefully allow you to have something along
Shimshon Duvdevan wrote:
[ ... Solaris - PTHREAD_SCOPE_SYSTEM ... ]
Can anyone verify the supposed boost threads library behavior on a
multi-processor Solaris machine? Is this behavior the intended one?
Perhaps a bug fix is necessary.
That's Solaris' bug and actually, they've already
William E. Kempf wrote:
[...]
Yes, this is trivially implemented with boost::thread_specific_ptr.
Well, it may require the use of boost::once() as well, which complicates
things a little, but it's not that bad.
Really? Well, you might want to take a look at this:
http://tinyurl.com/4xw6
Philippe A. Bouchard wrote:
[...]
Now, it's been a while I did not worked on any locking mechanism but if I am
accessing one counter and the increment instruction is atomic, why would I
need to lock anything?
You'll need the locking protocol/memory synchronization to
ensure visibility of
William E. Kempf wrote:
[...]
Recovery is hardly meaningless in this case. The recovery consisted of
informing the user of his mistake,
I'd say application's environmental problems [or something like
that] that can't be handled/recovered from by the application...
but it actually MAY try to
William E. Kempf wrote:
[...]
optional groups, but only two (assuming UNIX specification conformance
instead of just POSIX... is that a reasonable thing to do here?
Well, you might want to take a look at the current industry standards
{draft} paper referenced in the following message:
Beman Dawes wrote:
[...]
Interesting. I spent about fifteen minutes with Google and The Open Group's
search feature and couldn't come up with a formal specification for what
threading options are mandatory for version 3. Was the same division
into just two flavors (first four options now
1 - 100 of 107 matches
Mail list logo
