Re: [Tarantool-patches] [PATCH 1/5] popen: Introduce a backend engine

[Konstantin Osipov <kostja.osipov@gmail.com>]

* Cyrill Gorcunov <gorcunov@gmail.com> [19/11/28 23:46]:
>  - environment variables are flushed to zero, should we provide
>    a way to adjust it (via options) or inherit it instead?

Yes. You can take a look at Python Popen api for inspiration.

>  - popen_kill always send SIGKILL, should not we provide a
>    portable way to customize signal sedning (say symbolic
>    names for signals and pass them here)?

Again, you could take a look at Python - they have kill()
and terminate(), which allows for platform-agnostics hard and soft 
termination. Sending Unix signals to processes can be done by signal()
system call, so you don't need to worry about providing an API
for it in Popen, as long as you expose the child pid in the api.

>  - for native mode we don't do additional processing of arguments
>    thus only plain name of elf executable will be working, we
>    should provide a way for argv explicit passing or
>    do analyze @command for arguments by hands;

>  - need to consider a case where we will be using piping for
>    descriptors (for example we might be writting into stdin
>    of a child from another pipe, for this sake we could use
>    splice() syscall which gonna be a way faster than copying
>    data inside kernel between process). Still the question
>    is -- do we really need it? Since we use interanal flags
>    in popen handle this should not be a big problem to extend
>    this interfaces.

Not in the first version for sure. 
>  	title_free(main_argc, main_argv);
>  
> +	popen_fini();

The convention is to use new/delete for functions which
allocate + initialize and destroy + deallocate an object.

create/destroy for functions which initialize/destroy an object
but do not handle memory management.

init/free for functions which initialize/destroy libraries and
subsystems. Please stick to it.

-- 
Konstantin Osipov, Moscow, Russia