Farid Zaripov wrote:
-----Original Message-----
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Friday, July 21, 2006 6:32 PM
To: [email protected]
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
rw_process_createxx
similar to a set of functions execxx.
Plus the function
rw_create_process (without suffixes) with the interface like
rw_system().
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.
Martin
