GNOME Bugzilla – Bug 528285
Glib::spawn_async* functions need overloads without the child_setup param
Last modified: 2015-01-11 14:33:53 UTC
If you don't need to do any setup for the child process, you shouldn't have to pass a child_setup function. In fact, if you try to do it on windows, it will print a warning on the terminal: (GTKonsole.exe:1552): GLib-WARNING **: passing a child setup function to the g_spawn functions is pointless and dangerous on Win32 foo()
Feel free to commit that API addition.
The child_setup parameter already has a default value (an empty/invalid slot<>), though it is not at the end. Is it worth adding another method overload just to make it explicitly clear that this one parameter can really be ignored?
Note that we now have the {?} syntax to do this automatically.
Created attachment 293046 [details] [review] patch: Add Glib::spawn_no_child_setup() The {?} syntax is not applicable here, for two reasons. 1. {?} is used in gmmproc's _WRAP_METHOD directive. The spawn functions are hand-coded. 2. {?} would generate an extra overloaded function. That would make many calls to the spawn functions ambiguous. Example: void spawn_async(const std::string& working_directory, const Glib::ArrayHandle<std::string>& argv, SpawnFlags flags = SPAWN_DEFAULT, const sigc::slot<void>& child_setup = sigc::slot<void>(), Pid* child_pid = 0); Add the overload void spawn_async(const std::string& working_directory, const Glib::ArrayHandle<std::string>& argv, SpawnFlags flags = SPAWN_DEFAULT, Pid* child_pid = 0); and the call Glib::spawn_async(dir, argv); becomes ambiguous. It would be possible to add new functions with other names, e.g. void spawn_async_without_child_setup(const std::string& working_directory, const Glib::ArrayHandle<std::string>& argv, SpawnFlags flags = SPAWN_DEFAULT, Pid* child_pid = 0); But is it really worth adding 6 new functions? My answer is: No. I suggest that I push the attached patch, which makes it possible to write more understandable calls to the spawn functions, and then close this bug.
I've changed my mind, and pushed a patch that adds typedef sigc::slot<void> SlotSpawnChildSetup; and says in the documentation that the child_setup parameters can be empty slots. Typedefs are not part of the ABI. This change does not break ABI or API. https://git.gnome.org/browse/glibmm/commit/?id=330c814b74c85d4d5c80feedf6f6aa6c7226ab1a Even though this is some kind of fix, it's not the kind of fix that Jonathon wants (or wanted). WONTFIX is a reasonable resolution.