stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: string methods thread safety
Date Wed, 26 Jul 2006 17:34:41 GMT
Farid Zaripov wrote:

>>-----Original Message-----
>>From: Martin Sebor [] 
>>Sent: Friday, July 21, 2006 6:32 PM
>>Subject: Re: string methods thread safety
>>>  Since rw_process_create just calls execv() after fork() I 
>>think that 
>>>it will be useful create a full set of functions 
>>>similar to a set of functions execxx.
>>>Plus the function
>>>rw_create_process (without suffixes) with the interface like 
>>I would keep it simple. In the mt test you've used the argv 
>>overload where it looks to me like the vararg function (i.e,, 
>>analogous to rw_system()) might be easier to work with.
>   I think the thread safety test driver should pass all own parameters
> to the child copies.
> Then it's will be possible to run test with some test cases disabled
> (i.e. specify
> --no-UserChar parameter to disable the tests with
> std::basic_string<UserChar>).

Yes, that makes sense (although the child will somehow need
to be told that it's a child of another test test and not
the parent itself).

> With argv overload I simple add the additional parameters to the
> existing.
> With vararg overload is necessary to combine the existent parameters to
> the solid
> string before call of the rw_process_create() and then split it back
> before call of
> the execxx(). Maybe I missed something?

I don't think you did. It just looked to me like the parent
was doing the argv shuffle ;-) that could have been avoided
if we had the vararg function. Btw., it wouldn't be too hard
to provide the ability to pass all of argv to the vararg
function as well. Something like
   rw_process_create("./a.out $*", argv)
(where $* is the shell variable representing the shell's
command line arguments). Or we could use/extend one of the
rw_printf formatting directives (e.g., "%{*As}" to go with
"%{*Ac}"). I think I like that even better because it's
more general and might be useful elsewhere.


View raw message