[Geany-Devel] Spawn module API
dimitar.zhekov at xxxxx
Thu Jun 25 16:39:00 UTC 2015
On 24.6.2015 г. 02:05, Colomban Wendling wrote:
> IMO, spawn_with_callbacks() is *the* key API from spawn, what makes it
It is, indeed.
> spawn_async_with_pipes() can be nice, but most people probably shouldn't
> use them as they have same IO trickery most IO layers have, where you
> have to take care of not filling up any pipes (write) or forget to empty
> them (read).
It's doccomment specially says "use spawn_with_callbacks() unless you
need to setup specific event sources". Equivalent to glib
g_spawn_async_with_pipes - shoot yourself in the foot. I'm not opposed
to hiding it completely.
> BTW, I just noticed that on Windows spawn_async_with_pipes() requires
> the GLib main loop to be running if child_pid=NULL (well, it registers a
> watch func, not sure what happens if it doesn't execute -- zombie?).
> We probably don't care much though.
I should check that, and either document it, or remove support for
child_pid = NULL - especially if the function is hidden.
> spawn_async() doesn't seem so much useful to me, [...]
> spawn_sync() is nice because it allows to easily pipe through a process
> (send some data to stdin and and read the output). How often is this
> useful for everyone I don't know [...]
I wrote those for completeness, as equivalents to g_spawn_[a]_sync.
Though the prototypes are different, and spawn_sync supports binary I/O.
The reasons I mentioned before apply - no helper process, native command
line, better locale support, and likely improved security.
> spawn_get_exit_status_cb() seem useless to the API IMO. It's a trivial
> function currently only used by spawn itself. It might even be sensible
> to make it completely internal.
I'm not against it.
> I would have said that spawn_write_data() wasn't really required because
> it's relatively simple and not used by Geany outside of spawn, but it's
> indeed probably handy in combination with spawn_with_callbacks() to
> anyone wanting to feed a simple buffer to stdin.
spawn_write_data() can be used either directly as a callback, or invoked
by a more complex callback, which would probably be the case with Scope.
It's indeed simple (if you know that the optimal read size under Windows
is 2K), but do we need to repeat it, or write something similar, each
time we want to write something to child's stdin?
> spawn_get_program_name() is only used in spawn itself and doesn't seem
> to be a strict requirement.
May be handy to get the program name from a command line... but most
people would probably need spawn_check_command().
> spawn_check_command() seem nice to validate a user command before
> actually running it, so it might be useful to anyone wanting to run
> user-supplied commands through the spawn API, to e.g. check for issues
> right when the user defines the command (like how we do it in the custom
> commands dialog).
Any plugin that lets you define a command line may benefit from it.
For now, I plan a per-program gdb executable setting in Scope, but
without any gdb options, and thus don't need it...
More information about the Devel