[Geany-Devel] Spawn module API

[Dimitar Zhekov]

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