|
From: | Michael D Godfrey |
Subject: | Re: wait_for_file ?? [print via pipes - help testing on Windows?] |
Date: | Sat, 18 Sep 2010 09:12:52 -0700 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100907 Fedora/3.1.3-1.fc13 Thunderbird/3.1.3 |
On 09/18/2010 07:59 AM, Ben Abbott wrote:
You may want to recall the requirement from "man popen": The return value from popen() is a normal standard I/O stream in all respects save that it must be closed with pclose() rather than fclose(3). Writing to such a stream writes to the standard input of the command; the command’s standard output is the same as that of the process that called popen(), unless this is altered by the command itself. Conversely, reading from a "popened" stream reads the command’s standard output, and the command’s standard input is the same as that of the process that called popen(). Note that output popen() streams are fully buffered by default. The pclose() function waits for the associated process to terminate and returns the exit status of the command as returned by wait4(2). ====================================== Therefore you should be using pclose() not fclose(). But also note, as Shai pointed out, the call to the gl2ps code passes pid by value so the first of the 2 examples above is more nearly correct. Actually, the pclose is probably not necessary, and I think that the gl2ps code does a waitpid before its pclose, so the waitpid may not be required either. However, if control returns from the fprintf() before the gl2ps code has entered the section that uses the passed pid, the closes could be harmful. Michael |
[Prev in Thread] | Current Thread | [Next in Thread] |