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

[Cyrill Gorcunov]

On Fri, Nov 29, 2019 at 05:50:28PM +0300, Konstantin Osipov wrote:
> * Cyrill Gorcunov <gorcunov at gmail.com> [19/11/29 16:31]:
> > And how it is different from fio.write()? I mean I don't understand
> > why for regular writes in fio.write() we call for coio and for
> > popen we should not do the same.
> 
> Cyrill, the difference is popen works with a pipe, not a file.
> Unix supports non-blocking IO for pipes, and usually it doesn't
> support it for files. 

OK, i've got what you mean. Kostya, let me express some more details
on current implementation, maybe I simply miss something obvious:

1) The pipes I use are opened in blocking mode, non-blocking read
   implemented via explicit call to poll() with timeout option
   (to be honest I'm a bit worried about signal interruption from
    timers which libev provides, won't they interrupt poll since
    they all are living in same thread, I need to understand this
    moment later).

   IOW, using pipes in blocking mode and poll with timeout for
   nonblocking read is correct solution or we shoudl use nonbloking
   ops from the very beginning?

2) When I do various ops on popen object (say sending kill, fetching
   status of a process and etc) I block SIGCHLD of coio thread,
   otherwise there is a race with external users which could simply
   kill the "command" process we're running and popen->pid no longer
   valid, what is worse someone else could be take this pid already.

   Thus I need to block signals for this sake, and now if I start
   calling the popen helpers without entering coio thread (ie without
   coio_custom helpers) I wont be able to block signals. If I understand
   correctly the console is running inside own thread, no?