On 9/24/12 11:06 PM, Stefan Teleman wrote:
On Mon, Sep 24, 2012 at 7:48 PM, Liviu Nicoara wrote:
Stefan, was it your intention to completely eliminate all the race
conditions with this last patch? Is this what the tools showed in your
environment?
https://issues.apache.org/jira/browse/STDCX
On Tue, Sep 25, 2012 at 7:41 AM, Liviu Nicoara wrote:
> Caching failures aside, we have no failing tests. Before saying they are
> malign you need to objectively show a failing program.
>
> Martin's example above is a read-write race. In the absence of a failing
> test case it is quite unreasona
On 09/24/12 23:50, Stefan Teleman wrote:
On Mon, Sep 24, 2012 at 10:03 PM, Martin Sebor wrote:
FWIW, there are race conditions in stdcxx. Some of them are by
design and benign on the systems the library runs on (although
I acknowledge that some others may be bugs). One such benign
date race is:
On 09/24/12 22:28, Martin Sebor wrote:
On 09/20/2012 06:46 PM, Stefan Teleman wrote:
On Thu, Sep 20, 2012 at 8:39 PM, Liviu Nicoara wrote:
I have not created this requirement out of thin air. STDCXX development has
functioned in this manner for as long as I remember. If it does not suit you,
On Mon, Sep 24, 2012 at 10:03 PM, Martin Sebor wrote:
> FWIW, there are race conditions in stdcxx. Some of them are by
> design and benign on the systems the library runs on (although
> I acknowledge that some others may be bugs). One such benign
> date race is:
>
> timeT1 T2
> 0
On Mon, Sep 24, 2012 at 7:48 PM, Liviu Nicoara wrote:
> Stefan, was it your intention to completely eliminate all the race
> conditions with this last patch? Is this what the tools showed in your
> environment?
>> https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.s
On 09/20/2012 06:46 PM, Stefan Teleman wrote:
On Thu, Sep 20, 2012 at 8:39 PM, Liviu Nicoara wrote:
I have not created this requirement out of thin air. STDCXX development has
functioned in this manner for as long as I remember. If it does not suit you,
that's fine.
That would explain why
FWIW, there are race conditions in stdcxx. Some of them are by
design and benign on the systems the library runs on (although
I acknowledge that some others may be bugs). One such benign
date race is:
timeT1 T2
0x = N
1x = N read x
where x is a scalar that can be acc
On 9/24/12 12:06 AM, Stefan Teleman wrote:
On Fri, Sep 21, 2012 at 9:10 AM, Liviu Nicoara wrote:
On 09/21/12 05:13, Stefan Teleman wrote:
On Fri, Sep 21, 2012 at 2:28 AM, Travis Vitek
wrote:
I have provided this list with test results showing that my patch
*does* fix the race condition prob
On Fri, Sep 21, 2012 at 9:10 AM, Liviu Nicoara wrote:
> On 09/21/12 05:13, Stefan Teleman wrote:
>>
>> On Fri, Sep 21, 2012 at 2:28 AM, Travis Vitek
>> wrote:
>>
>> I have provided this list with test results showing that my patch
>> *does* fix the race condition problems identified by all the to
> -Original Message-
> From: Stefan Teleman [mailto:stefan.tele...@gmail.com]
> Sent: Friday, September 21, 2012 2:14 AM
> To: dev@stdcxx.apache.org
> Subject: Re: STDCXX-1056 : numpunct fix
>
> On Fri, Sep 21, 2012 at 2:28 AM, Travis Vitek
> wrote:
>
&
On 09/21/12 05:13, Stefan Teleman wrote:
On Fri, Sep 21, 2012 at 2:28 AM, Travis Vitek
wrote:
I have provided this list with test results showing that my patch
*does* fix the race condition problems identified by all the tools at
my disposal. I'm willing to bet you never looked at it. You dismi
On Fri, Sep 21, 2012 at 2:28 AM, Travis Vitek
wrote:
> You called out premature optimization as evil, in a discussion about patches
> you provided that include optimizations and no testcase showing that your
> changes are not premature and provide measureable benefit. Then you rail on...
I did
> -Original Message-
> From: Stefan Teleman
> Sent: Thursday, September 20, 2012 6:00 PM
> To: dev@stdcxx.apache.org
> Cc: Liviu Nicoara
> Subject: Re: STDCXX-1056 : numpunct fix
>
> On Thu, Sep 20, 2012 at 8:44 PM, "C. Bergström"
> wrote:
>
>
On Sep 20, 2012, at 8:59 PM, Stefan Teleman wrote:
> On Thu, Sep 20, 2012 at 8:44 PM, "C. Bergström"
> wrote:
>
>>
>> fencepost comment - The results are based on tools and I don't think he has
>> a large program which actually triggers the conditions. (Creating one may
>> take quite some tim
On Thu, Sep 20, 2012 at 8:44 PM, "C. Bergström"
wrote:
>
> fencepost comment - The results are based on tools and I don't think he has
> a large program which actually triggers the conditions. (Creating one may
> take quite some time)
I do have a program which triggers the race conditions:
On Thu, Sep 20, 2012 at 8:39 PM, Liviu Nicoara wrote:
> I have not created this requirement out of thin air. STDCXX development has
> functioned in this manner for as long as I remember. If it does not suit you,
> that's fine.
That would explain why these bugs are present in the first place.
On 09/21/12 07:39 AM, Liviu Nicoara wrote:
Now, in all honesty, it is not too hard to do that. Once you can satisfactorily
explain to yourself what is wrong in the program, the creation of a test case
is trivial. Some multi-threading bugs are insidious and hard to reproduce, but
even then it's
On Sep 20, 2012, at 8:24 PM, Stefan Teleman wrote:
> On Thu, Sep 20, 2012 at 8:18 PM, Liviu Nicoara wrote:
>
>> That is not it, and you did not. Please pay attention: given your assertion
>> that a race condition is a defect that causes an abnormal execution of the
>> program during which the
On Thu, Sep 20, 2012 at 8:18 PM, Liviu Nicoara wrote:
> That is not it, and you did not. Please pay attention: given your assertion
> that a race condition is a defect that causes an abnormal execution of the
> program during which the program sees abnormal, incorrect states (read:
> variable
On Sep 20, 2012, at 8:02 PM, Stefan Teleman wrote:
> On Thu, Sep 20, 2012 at 7:52 PM, Liviu Nicoara wrote:
>>
>> On Sep 20, 2012, at 7:49 PM, Stefan Teleman wrote:
>>
>>> On Thu, Sep 20, 2012 at 7:40 PM, Liviu Nicoara wrote:
>>>
The only gold currency that anyone in here accepts without
On Thu, Sep 20, 2012 at 8:04 PM, Wojciech Meyer
wrote:
> Therefore please use tools but be a bit reserved for the results.
I *am* being cautiously skeptical about the results. That's why I am
using 4 [ FOUR ] different thread analyzers, on three different
operating systems, each one of them in
Liviu Nicoara writes:
> On Sep 20, 2012, at 5:23 PM, Stefan Teleman wrote:
>
>> On Thu, Sep 20, 2012 at 4:45 PM, Travis Vitek
>> wrote:
>>
I'll let you in on a little secret: once you call setlocale(3C) and
localeconv(3C), the Standard C Library doesn't release its own locale
On Thu, Sep 20, 2012 at 7:52 PM, Liviu Nicoara wrote:
>
> On Sep 20, 2012, at 7:49 PM, Stefan Teleman wrote:
>
>> On Thu, Sep 20, 2012 at 7:40 PM, Liviu Nicoara wrote:
>>
>>> The only gold currency that anyone in here accepts without reservations are
>>> failing test cases. I believe I have seen
On Sep 20, 2012, at 7:49 PM, Stefan Teleman wrote:
> On Thu, Sep 20, 2012 at 7:40 PM, Liviu Nicoara wrote:
>
>> The only gold currency that anyone in here accepts without reservations are
>> failing test cases. I believe I have seen some exceptions to the golden rule
>> in my RW time, but I c
On Sep 20, 2012, at 7:45 PM, Stefan Teleman wrote:
> On Thu, Sep 20, 2012 at 7:22 PM, Liviu Nicoara wrote:
>
>> Stefan, I want to be clear. You are talking about a patch identical in
>> nature to the one I have attached now. Just want to be 100% sure we are
>> talking about the same thing. Th
On Sep 20, 2012, at 5:23 PM, Stefan Teleman wrote:
> On Thu, Sep 20, 2012 at 4:45 PM, Travis Vitek
> wrote:
>
>>>
>>> I'll let you in on a little secret: once you call setlocale(3C) and
>>> localeconv(3C), the Standard C Library doesn't release its own locale
>>> handles until process terminat
On Thu, Sep 20, 2012 at 7:22 PM, Liviu Nicoara wrote:
> Stefan, I want to be clear. You are talking about a patch identical in nature
> to the one I have attached now. Just want to be 100% sure we are talking
> about the same thing. This one still produces failures (crashes, assertions,
> etc.
On Sep 20, 2012, at 7:37 PM, Stefan Teleman wrote:
> On Thu, Sep 20, 2012 at 7:34 PM, Wojciech Meyer
> wrote:
>> Hi,
>>
>> My perceptions is by reading through the whole thread - we should not
>> trust 100% external tools to asses the safety of the code. I don't think
>> there exist an algorith
On Thu, Sep 20, 2012 at 7:34 PM, Wojciech Meyer
wrote:
> Hi,
>
> My perceptions is by reading through the whole thread - we should not
> trust 100% external tools to asses the safety of the code. I don't think
> there exist an algorithm that produces no false positives.
>
> That's said I admire St
Hi,
My perceptions is by reading through the whole thread - we should not
trust 100% external tools to asses the safety of the code. I don't think
there exist an algorithm that produces no false positives.
That's said I admire Stefan's approach, but we should ask the question
are we MT safe enoug
On Sep 20, 2012, at 5:31 PM, Stefan Teleman wrote:
> On Thu, Sep 20, 2012 at 5:07 PM, Liviu Nicoara wrote:
>
> To answer your question [...]:
> yes, the MT failures occur on SPARC as well, on both SPARCV8 and
> SPARCV9, and the race conditions are reported on *ALL* plaforms
> tested, even afte
On Thu, Sep 20, 2012 at 5:07 PM, Liviu Nicoara wrote:
> Stefan, you are not being correct by a consensus of thread analyzers output
> or by being loud, or by pounding your fist on the table. This being said I
> will continue to exercise due diligence and put in the necessary time and
> effort to
On Thu, Sep 20, 2012 at 4:45 PM, Travis Vitek
wrote:
>>
>> I'll let you in on a little secret: once you call setlocale(3C) and
>> localeconv(3C), the Standard C Library doesn't release its own locale
>> handles until process termination. So you might think you save a lot
>> of memory by destroyin
On 09/20/12 13:11, Stefan Teleman wrote:
On Thu, Sep 20, 2012 at 8:07 AM, Liviu Nicoara wrote:
But have you measured the amount of memory consumed by all STDCXX locale data
loaded in one process? How much absolute time is spent in resizing the locale
and facet buffers? What is the gain in spa
> -Original Message-
> From: Stefan Teleman [mailto:stefan.tele...@gmail.com]
> Sent: Thursday, September 20, 2012 10:11 AM
> To: dev@stdcxx.apache.org
> Subject: Re: STDCXX-1056 : numpunct fix
>
> On Thu, Sep 20, 2012 at 8:07 AM, Liviu Nicoara
> wrote:
>
On Thu, Sep 20, 2012 at 8:07 AM, Liviu Nicoara wrote:
> But have you measured the amount of memory consumed by all STDCXX locale data
> loaded in one process? How much absolute time is spent in resizing the locale
> and facet buffers? What is the gain in space and time performance with such a
>
Thanks for the feed-back. Please see below.
On Sep 19, 2012, at 10:02 PM, Stefan Teleman wrote:
> On Wed, Sep 19, 2012 at 8:51 PM, Liviu Nicoara wrote:
>
>> I think you are referring to `live' cache objects and the code which
>> specifically adjusts the size of the buffer according to the numb
On Wed, Sep 19, 2012 at 8:51 PM, Liviu Nicoara wrote:
> I think you are referring to `live' cache objects and the code which
> specifically adjusts the size of the buffer according to the number of
> `live' locales and/or facets in it. In that respect I would not call that
> eviction because loca
On 09/19/12 13:56, Stefan Teleman wrote:
This is a proposed fix for the numpunct facet for stdcxx-1056:
FWIW, here is my feed-back. Please correct me if there is something I
did not get right about your proposed patch:
0. Number of reported race conditions is now 0 (zero).
1. No memory
This is a proposed fix for the numpunct facet for stdcxx-1056:
0. Number of reported race conditions is now 0 (zero).
1. No memory leaks in stdcxx (there are memory leaks reported in either
libc or glibc, but there's nothing we can do about these anyway).
2. This fix preserves perfect for
41 matches
Mail list logo
