stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Farid Zaripov <>
Subject RE: string methods thread safety
Date Wed, 26 Jul 2006 19:00:50 GMT
 > -----Original Message-----
 > From: Martin Sebor []
 > Sent: Friday, July 21, 2006 4:00 AM
 > To:
 > Subject: RE: string methods thread safety
 > Could you please post your proposed ChangeLog entry for all
 > nontrivial changes? It will make it easier for me to
 > understand what's going on.
 > Thanks! :)

   The test exercising string thread safety (
The test file and 21.string.*.diff are attached.
The test requires the files rw_process.h and process.cpp (I have sent
this files in the separate letter).

   At first the test checks were option --overload_id=xxx is specified.
If the option is not specified it executes the self copy with
the all own and the three additional parameters:
1) --overload_id={one of the exercising StringIds::OverloadId};
2) --no-stdout to prevent the output of the copy process to the
test driver console;
3) --no-UserAlloc to prevent UserAlloc allocator using
due to SharedAlloc (used by UserAlloc) is not a thread safe.

   The child copy is executed for each overload id from overloads array.
When the parameter --overload_id=xxx is specified the test performs the 
thread safety test of the specified overload. If shared string is 
modified after the test, the global variable _rw_status is set to 1 (to 
detect the string modification I had to slightly modify the 
StringState::assert_equal() method). This variable is a return code of 
the child process to transfer the success of the overload test to the 
driver (parent process). I used the global variable because the callback 
for rw_run_string_test() returns void.

   For the range overloads (append_range, assign_range, 
insert_iter_range, replace_iter_iter_range) the 
basic_string<>::const_iterator overloads tested only. I am not sure that 
it's enough, but I can add testing of the other overloads later.

   When the parent process receives the return code it checks this by 
rw_assert(). To print the method signature I used _rw_setvars from 
21.strings.cpp. For this I renamed it to rw_setvars due to naming 
conventions. I don't like it too, but I have no the better idea yet.

 > The only thing I'm not quite happy with so far is making
 > _rw_setvars extern. According to the (still unwritten, my
 > bad) naming convention, names that start with _rw_ have
 > internal linkage, and shouldn't be exposed to the world
 > (i.e., to the tests or other objects). If it turns out that
 > the function is helpful elsewhere besides the TU where it's
 > declared static we should rename it (and drop the leading
 > underscore). The burden that should come with doing it is
 > writing a test for the function.


View raw message