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.
Martin
