Re: POpen en PClose
Adriaan van Os via fpc-pascal <[email protected]> Mon, 20 Jul 2026 18:29:52 +0000 (UTC)
| Newsgroups | gmane.comp.compilers.free-pascal.general |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============2086401563605368710==
Content-Type: multipart/alternative;
boundary="------------b29rptcpSPUrDo3Kfjn9UQzB"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------b29rptcpSPUrDo3Kfjn9UQzB
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
On 20/07/2026 19:56, Adriaan van Os via fpc-pascal wrote:
>
>
> On 20/07/2026 16:19, Marco van de Voort via fpc-pascal wrote:
>>
>> Op 20-7-2026 om 15:13 schreef Adriaan van Os via fpc-pascal:
>>>>
>>>> So popen/pclose are a more high level (FILE * using) part of libc,
>>>> while we tend to only use the basis.
>>>
>>> Ah, so that means that I couldn't just call naively into libc popen
>>> with FileRec.Handle ?
>>>
>> Indeed. And FILE* is opague and thus target specific, it would
>> mean another structure to maintain, and to somehow to determine for a
>> new *nix target. STAT and STATFS already give us grief enough.
>
> Right. So now I am calling PClose and it will hang. Why ? Well, PClose
> calls WaitProcess in unx.pp, which in turn calls fpWaitPid in a loop,
> which returns (on Darwin) 0 for a process that has died ....
>
> repeat
> r:=fpWaitPid(Pid,@s,0);
> if (r=-1) and (fpgeterrno=ESysEIntr) Then
> r:=0;
> until (r<>0);
>
> In general, I find such a loop, that depends on result codes, quite
> risky. The POSIX standard says here
> <https://pubs.opengroup.org/onlinepubs/9699919799/functions/wait.html>
>
> "If/wait/() or/waitpid/() return because the status of a child
> process is available, these functions shall return a value equal to
> the process ID of the child process. In this case, if the value of the
> argument/stat_loc/is not a null pointer, information shall be stored
> in the location pointed to by/stat_loc/. The value stored at the
> location pointed to by/stat_loc/shall be 0 if and only if the status
> returned is from a terminated child process that terminated by one of
> the following means:"
This is nonsense. I apologize for the noise. The reason for the hang is
not the loop but the child process that has not terminated.
By the way, how do I flush the output to the POpen child process ? I
tried SysUtils.FileFlush with FileRec( File).Handle. but it failed.
Regards,
Adriaan van Os
--------------b29rptcpSPUrDo3Kfjn9UQzB
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 20/07/2026 19:56, Adriaan van Os via
fpc-pascal wrote:<br>
</div>
<blockquote type="cite"
cite="mid:3ecc06c8-5929-4787-adb3-8109d5edf3a2-Cc4Ncl17NrGpwFb5G8XvHQ@public.gmane.org"> <br>
<br>
<div class="moz-cite-prefix">On 20/07/2026 16:19, Marco van de
Voort via fpc-pascal wrote:<br>
</div>
<blockquote type="cite"
cite="mid:1e42618f-b947-4f98-83ae-ed562439302d-wEdTOCGUvwedTX5a5knrmyH1kwoRJHTR@public.gmane.org"> <br>
Op 20-7-2026 om 15:13 schreef Adriaan van Os via fpc-pascal: <br>
<blockquote type="cite">
<blockquote type="cite"> <br>
So popen/pclose are a more high level (FILE * using) part of
libc, while we tend to only use the basis. <br>
</blockquote>
<br>
Ah, so that means that I couldn't just call naively into libc
popen with FileRec.Handle ? <br>
<br>
</blockquote>
Indeed. And FILE* is opague and thus target specific, it
would mean another structure to maintain, and to somehow to
determine for a new *nix target. STAT and STATFS already give us
grief enough. <br>
</blockquote>
<br>
Right. So now I am calling PClose and it will hang. Why ? Well,
PClose calls WaitProcess in unx.pp, which in turn calls fpWaitPid
in a loop, which returns (on Darwin) 0 for a process that has died
....<br>
<br>
repeat<br>
r:=fpWaitPid(Pid,@s,0);<br>
if (r=-1) and (fpgeterrno=ESysEIntr) Then<br>
r:=0;<br>
until (r<>0);<br>
<br>
In general, I find such a loop, that depends on result codes,
quite risky. The POSIX standard says here
<a class="moz-txt-link-rfc2396E"
href="https://pubs.opengroup.org/onlinepubs/9699919799/functions/wait.html"
moz-do-not-send="true"><https://pubs.opengroup.org/onlinepubs/9699919799/functions/wait.html></a><br>
<br>
<span> "If<span class="Apple-converted-space"> </span></span><i>wait</i><span>()
or<span class="Apple-converted-space"> </span></span><i>waitpid</i><span>()
return because the status of a child process is available, these
functions shall return a value equal to the process ID of the
child process. In this case, if the value of the argument<span
class="Apple-converted-space"> </span></span><i>stat_loc</i><span>is
not a null pointer, information shall be stored in the location
pointed to by<span class="Apple-converted-space"> </span></span><i>stat_loc</i><span>.
The value stored at the location pointed to by<span
class="Apple-converted-space"> </span></span><i>stat_loc</i><span><span
class="Apple-converted-space"> </span>shall be 0 if and only
if the status returned is from a terminated child process that
terminated by one of the following means:"<br>
</span></blockquote>
<br>
This is nonsense. I apologize for the noise. The reason for the hang
is not the loop but the child process that has not terminated.<br>
<br>
By the way, how do I flush the output to the POpen child process ? I
tried SysUtils.FileFlush with FileRec( File).Handle. but it failed.<br>
<br>
Regards,<br>
<br>
Adriaan van Os<br>
<br>
<br>
</body>
</html>
--------------b29rptcpSPUrDo3Kfjn9UQzB--
--===============2086401563605368710==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
fpc-pascal maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
--===============2086401563605368710==--