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 Fri, 21 Jul 2006 15:31:35 GMT
Farid Zaripov wrote:
>>Wouldn't something closer to 
>>rw_system() be easier to use? (If so, you might want to move 
>>rw_process_create to the .cpp file and make it static and 
>>call it from the new vararg function).
>   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 can the utility of of
the execv-style signature as well but I would keep it at that (i.e.,
no need to add rw_execl() or the other variants). As for the path
argument, I think the behavior of execvp() makes the most sense,
do you agree?

>>>+    // the child process
>>>+    execv (path, argv);
>>>+    // the execvp returns only if an error occurs
>>>+    rw_fatal (0, __FILE__, __LINE__, "execvp failed: : 
>>errno = %{#m} 
>>>+ (%{m})");
>>>+    exit (1);
>>FYI: rw_fatal() doesn't return so there's no need to call exit().
>>I'm not sure rw_fatal() is appropriate, though. The test 
>>might be able to continue with other things after a failure.
>   I think in that case the test shouldn't to continue because after a
> fork() succeeded
> it will be a copy of the parent process. What for to continue a child
> copy?

Good point! I forgot about the fork. With that in mind I think
we definitely want to exit as soon as possible and probably w/o
calling into the driver, certainly without calling rw_fatal()
since it produces the summary output before exiting with a non
zero status.


View raw message