On 24.6.2015 г. 02:05, Colomban Wendling wrote:
IMO, spawn_with_callbacks() is *the* key API from spawn, what makes it
great.
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...
--
E-gards: Jimmy
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
