我正在尝试从C程序派生一个子进程来运行python脚本,该脚本应在其stdin上处理来自父代的行,并在stdout上将结果返回给父代。父级将输入输入行并从子级标准输出读取结果。
只有父母和孩子都被困在彼此读取第一行数据的地方。
想知道为什么,任何提示,TIA!
这里是运行C-parent的示例:
# ./pycalc
dude
Got this to do calc with: dude
^CTraceback (most recent call last):
File "./pycalc.py", line 9, in <module>
line=raw_input()
KeyboardInterrupt
这是示例python脚本:
#!/usr/bin/python
import base64
import os
line=''
while True:
try:
line=raw_input()
except EOFError:
break
print(base64.encodestring(line))
print('Bye - End of Calc!')
这是父级C源代码:
#define PARENT_READ read_pipe[0]
#define PARENT_WRITE write_pipe[1]
#define CHILD_WRITE read_pipe[1]
#define CHILD_READ write_pipe[0]
int main(int argc, char *argv[])
{
int pid;
int read_pipe[2];
int write_pipe[2];
FILE *wrp = (FILE *)NULL;
FILE *rdp = (FILE *)NULL;
char line[1024+1];
if ( pipe(read_pipe) < 0 ) exit(-1);
if ( pipe(write_pipe) < 0 ) exit(-1);
if ( (pid=fork()) < 0 )
exit(-1);
else if (pid == 0) {
// Child process go here
close(PARENT_READ);
close(PARENT_WRITE);
dup2(CHILD_READ, STDIN_FILENO);
dup2(CHILD_WRITE, STDOUT_FILENO);
close(CHILD_READ);
close(CHILD_WRITE);
setlinebuf(stdin);
setlinebuf(stdout);
const char *argv[] = {"pycalc.py",NULL};
execvp("pycalc.py", (char **)argv);
exit(errno);
}
// Parent process go here
close(CHILD_READ);
close(CHILD_WRITE);
if ( (wrp = fdopen(PARENT_WRITE, "w")) == NULL ) exit(-1);
setlinebuf(wrp);
if ( (rdp = fdopen(PARENT_READ, "r")) == NULL ) exit(-1);
setlinebuf(rdp);
while ( fgets(line, sizeof(line), stdin)!=NULL ) {
printf("Got this to do calc with: %s", line);
fprintf(wrp,"%s", line);
fflush(wrp);
fgets(line,sizeof(line),rdp);
printf("Got this calc from child: %s", line);
}
exit(0);
}
答案 0 :(得分:1)
我已经对自己设计的一些命令行工具进行了足够的实验,以使我确信问题是Python在此管道上下文中的工作方式。在获得EOF之前,它不会处理数据(因为输入的数据不足以填充缓冲区)。因此,尽管raw_input
尽了最大的努力,并尝试在执行Python之前设置行缓冲,但只要有行可用,它就不会读取数据。我的测试管道连续有6个进程:
timecmd -m -- cat -u | tstamp -f3 | tee /dev/tty | timecmd -m -- pycalc.py |
tstamp -f3 | tee $(isodate -c).log
timecmd
命令报告命令的开始时间,运行命令,并报告退出时间(-m
毫秒)。 tstamp -f3
在输出的每一行之前加上时间戳(-f3
毫秒)。使用cat -u
进行无缓冲输出;它会报告可用的行; tee /dev/tty
在终端上显示带有时间戳的输出,并将其反馈到pycalc.py
;输出会再次加上时间戳,然后通过管道传递到tee
进行日志记录(与isodate -c
的组合会生成日志文件名,例如20180924.072626.log
)。当我使用它时,我清楚地看到pycalc.py
不会做任何事情,直到我向cat -u
指示EOF。
$ timecmd -m -- cat -u | tstamp -f3 | tee /dev/tty | timecmd -m -- pycalc.py |
> tstamp -f3 | tee $(isodate -c).log
2018-09-24 07:29:06.419 [PID 44960] cat -u
2018-09-24 07:29:06.419 [PID 44961] pycalc.py
dude
2018-09-24 07:29:09.274: dude
how
2018-09-24 07:29:10.819: how
are
2018-09-24 07:29:12.349: are
you
2018-09-24 07:29:16.540: you
2018-09-24 07:29:26.205 [PID 44960; status 0x0000] - 19.786s
2018-09-24 07:29:26.209 [PID 44961; status 0x0000] - 19.789s
2018-09-24 07:29:26.208: MjAxOC0wOS0yNCAwNzoyOTowOS4yNzQ6IGR1ZGU=
2018-09-24 07:29:26.209:
2018-09-24 07:29:26.209: MjAxOC0wOS0yNCAwNzoyOToxMC44MTk6IGhvdw==
2018-09-24 07:29:26.209:
2018-09-24 07:29:26.209: MjAxOC0wOS0yNCAwNzoyOToxMi4zNDk6IGFyZQ==
2018-09-24 07:29:26.209:
2018-09-24 07:29:26.209: MjAxOC0wOS0yNCAwNzoyOToxNi41NDA6IHlvdQ==
2018-09-24 07:29:26.209:
2018-09-24 07:29:26.209: Bye - End of Calc!
$
因此,AFAICT,您需要找到一种方法,当标准输入来自管道时,使Python从标准输入中读取行,并在缓冲区已满之前读取它们。在那之前,您不会成功。在确保正确(及时)刷新输出时,您可能也会遇到类似的问题。您可以通过时间戳记Python看到的输入来进一步完善我所做的测试,也许将带有时间戳记的数据报告为标准错误(这样您就可以知道Python在做什么),但是我深信我的设置会及时将数据发送给Python,但Python没有意识到这一点。
Setting smaller buffer size for sys.stdin提出了使用“ python行缓冲标准输入”与Google进行搜索的建议,建议使用python -u
。当我在较长的命令行中使用timecmd -m -- python -u pycalc.py
时,将获得预期的输出-Python在生成数据时做出响应。
$ timecmd -m -- cat -u | tstamp -f3 | tee /dev/tty | timecmd -m -- python -u pycalc.py |
> tstamp -f3 | tee $(isodate -c).log
2018-09-24 07:52:41.485 [PID 45180] cat -u
2018-09-24 07:52:41.485 [PID 45181] python -u pycalc.py
dude
2018-09-24 07:52:43.213: dude
2018-09-24 07:52:43.214: MjAxOC0wOS0yNCAwNzo1Mjo0My4yMTM6IGR1ZGU=
2018-09-24 07:52:43.215:
how
2018-09-24 07:52:48.852: how
2018-09-24 07:52:48.852: MjAxOC0wOS0yNCAwNzo1Mjo0OC44NTI6IGhvdw==
2018-09-24 07:52:48.852:
are
2018-09-24 07:52:50.720: are
2018-09-24 07:52:50.720: MjAxOC0wOS0yNCAwNzo1Mjo1MC43MjA6IGFyZQ==
2018-09-24 07:52:50.720:
you
2018-09-24 07:52:52.479: you
2018-09-24 07:52:52.479: MjAxOC0wOS0yNCAwNzo1Mjo1Mi40Nzk6IHlvdQ==
2018-09-24 07:52:52.479:
2018-09-24 07:52:53.646 [PID 45180; status 0x0000] - 12.161s
2018-09-24 07:52:53.647: Bye - End of Calc!
2018-09-24 07:52:53.650 [PID 45181; status 0x0000] - 12.165s
$
您可以从时间戳中看到打字(故意慢打字)发生时的反应。将其转换为您的程序需要执行的操作,我想到了:
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#define PARENT_READ read_pipe[0]
#define PARENT_WRITE write_pipe[1]
#define CHILD_WRITE read_pipe[1]
#define CHILD_READ write_pipe[0]
int main(void)
{
int pid;
int read_pipe[2];
int write_pipe[2];
if (pipe(read_pipe) < 0)
exit(-1);
if (pipe(write_pipe) < 0)
exit(-1);
if ((pid = fork()) < 0)
exit(-1);
else if (pid == 0)
{
// Child process go here
close(PARENT_READ);
close(PARENT_WRITE);
dup2(CHILD_READ, STDIN_FILENO);
dup2(CHILD_WRITE, STDOUT_FILENO);
close(CHILD_READ);
close(CHILD_WRITE);
char *argv[] = {"python", "-u", "pycalc.py", NULL};
execvp(argv[0], argv);
fprintf(stderr, "failed to execute %s (%d: %s)\n", argv[0], errno, strerror(errno));
exit(errno);
}
// Parent process go here
close(CHILD_READ);
close(CHILD_WRITE);
FILE *wrp = fdopen(PARENT_WRITE, "w");
FILE *rdp = fdopen(PARENT_READ, "r");
if (wrp == NULL || rdp == NULL)
exit(-1);
setlinebuf(wrp);
setlinebuf(rdp);
char line[1024 + 1];
while (fgets(line, sizeof(line), stdin) != NULL)
{
printf("Got this to do calc with: %s", line);
fprintf(wrp, "%s", line);
fflush(wrp);
fgets(line, sizeof(line), rdp);
printf("Got this calc from child: %s", line);
}
return(0);
}
运行时(程序为pipe43
),我得到:
$ pipe43
dude
Got this to do calc with: dude
Got this calc from child: ZHVkZQ==
how
Got this to do calc with: how
Got this calc from child:
are
Got this to do calc with: are
Got this calc from child: aG93
you
Got this to do calc with: you
Got this calc from child:
Traceback (most recent call last):
File "pycalc.py", line 15, in <module>
print('Bye - End of Calc!')
IOError: [Errno 32] Broken pipe
$
Python的错误是因为它试图在父进程关闭其管道之后尝试写入-它不等待Python的杂散输出。
我不确定-u
选项对Python的效率影响;我怀疑它们不是很好。