Re: merging trunk to 4.2.0

2007-09-28 Thread Martin Sebor
Andrew Black wrote: Greetings Martin I suspect the cause of the subversion messages was because you were using a protocol of http, rather than https in the source tree. Hmm. I suppose it's possible, although I'm not sure why most files merged successfully and only the new ones failed. Maybe it

[jira] Updated: (STDCXX-452) std::numpunct not thread safe

2007-09-28 Thread Travis Vitek (JIRA)
[ https://issues.apache.org/jira/browse/STDCXX-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-452: Attachment: punct.patch 2007-09-28 Travis Vitek <[EMAIL PROTECTED]> STDCXX-452

RE: [PATCH] set id of user locale facets safely

2007-09-28 Thread Travis Vitek
Martin Sebor wrote: > >Travis Vitek wrote: >> >> The method for initializing the facet id is not currently >> thread safe. >> >> If a thread enters __rw_facet_id::_C_init() and is preempted after >> checking _C_id, a second thread can do the same check, increment the >> static counter, assign

[PATCH] __rw_setlocale not threadsafe

2007-09-28 Thread Travis Vitek
The __rw_setlocale destructor currently restores the previous locale when it isn't holding the lock. This can cause problems if another thread takes the lock and calls setlocale before the original thread restores the locale. I believe this problem to be the cause of the following failure that

Re: merging trunk to 4.2.0

2007-09-28 Thread Andrew Black
Greetings Martin I suspect the cause of the subversion messages was because you were using a protocol of http, rather than https in the source tree. Rel branch testing should begin when the archives are rebuilt tonight, unless you'd like me to get the ball rolling sooner. --Andrew Black Martin

Re: Out of date platform support listing?

2007-09-28 Thread Martin Sebor
Andrew Black wrote: Greetings all. I am glancing at the list of platforms we claim to support on our index page, and I'm questioning how accurate it is. As an example, we claim support for the 7.0 version of the Intel compiler, despite not having systematic tested anything older than the 9.0 ve

Re: [PATCH] 22.locale.moneypunct.mt.cpp test

2007-09-28 Thread Martin Sebor
Travis Vitek wrote: The same problem exists for __rw_get_numpunct. In that case we should probably make the same changes in both, referencing the respective issues in each ChangeLog, i.e., (presumably) STDCXX-453 in the patch below and STDCXX-452 in the one for __rw_get_numpunct. Martin Far

Re: [PATCH] set id of user locale facets safely

2007-09-28 Thread Martin Sebor
Travis Vitek wrote: The method for initializing the facet id is not currently thread safe. If a thread enters __rw_facet_id::_C_init() and is preempted after checking _C_id, a second thread can do the same check, increment the static counter, assign the facet id, and then return. The preempted

Re: [PATCH] 22.locale.moneypunct.mt.cpp test

2007-09-28 Thread Martin Sebor
Travis Vitek wrote: Martin Sebor wrote: I see what you're saying: the other thread will end up overwriting the data written by the first thread. The newly data should be the same, so I wonder if this just a benign race condition or if it's more sinister than that? It is a memory leak in th

Re: merging trunk to 4.2.0

2007-09-28 Thread Martin Sebor
The merge to branches/4.2.0 is complete now. Assuming our testing confirms that the merge was successful we'll tag it (4.2.0-rc-5) sometime next week. The merge was very difficult because of the large number of changes and because of what seems to be an svn limitation: the command line client croa

RE: [PATCH] 22.locale.moneypunct.mt.cpp test

2007-09-28 Thread Travis Vitek
Martin Sebor wrote: > >I see what you're saying: the other thread will end up overwriting >the data written by the first thread. The newly data should be the >same, so I wonder if this just a benign race condition or if it's >more sinister than that? > It is a memory leak in the failure case. T

Re: [PATCH] 22.locale.moneypunct.mt.cpp test

2007-09-28 Thread Martin Sebor
Farid Zaripov wrote: The __rw_get_moneypunct () function in punct.cpp is not thread safe for the same facets. If this function is invoked with the same pfacet parameter in dirrerent threads simultaneously, then some one thread successfully create __rw_setlocale object but other threads will blo

[PATCH] set id of user locale facets safely

2007-09-28 Thread Travis Vitek
The method for initializing the facet id is not currently thread safe. If a thread enters __rw_facet_id::_C_init() and is preempted after checking _C_id, a second thread can do the same check, increment the static counter, assign the facet id, and then return. The preempted thread would incremen

RE: [PATCH] 22.locale.moneypunct.mt.cpp test

2007-09-28 Thread Travis Vitek
The same problem exists for __rw_get_numpunct. Farid Zaripov wrote: > > The __rw_get_moneypunct () function in punct.cpp is not thread safe >for the same >facets. If this function is invoked with the same pfacet parameter in >dirrerent threads >simultaneously, then some one thread successfully c

[PATCH] 22.locale.moneypunct.mt.cpp test

2007-09-28 Thread Farid Zaripov
The __rw_get_moneypunct () function in punct.cpp is not thread safe for the same facets. If this function is invoked with the same pfacet parameter in dirrerent threads simultaneously, then some one thread successfully create __rw_setlocale object but other threads will blocked by global mutex in