On Fri, Sep 11, 2020 at 12:34 AM Shiro Kawai <xxxxxx@gmail.com> wrote:
>
> On Thu, Sep 10, 2020 at 6:16 AM Duy Nguyen <xxxxxx@gmail.com> wrote:
>>
>> On Thu, Sep 10, 2020 at 11:05 PM Lassi Kortela <xxxxxx@lassi.io> wrote:
>>
>> > A child process using a known fd number (e.g. 3) from its parent (or
>> > from its predecessor before execve()) is a good convention for IPC.
>> > Hence it ought to be a useful feature to open a known fd as a Scheme port.
>>
>> Yes. We can deal with that when we flesh out process management SRFI.
>> Until we know exactly the interface we have it may be premature to
>> introduce fd-based API.
>>
>
> It doesn't need to be related to process srfi.   The extra fd may be open by the parent process (which doesn't need to be a Scheme program), and the Scheme program may want to read/write the given integer fd.
>
> One real-world example is stunnel <https://www.stunnel.org/static/stunnel.html> .  It takes the -fd option, which takes an integer fd that the parent process is supposed to open before spawning the stunnel command.  Now, if we want to write a similar command in Scheme, it gets an integer fd from command line arguments and needs to read from it.

Yeah I'm thinking about that. And I don't have an answer yet (and
don't want to invoke that 80/20 rule). But I think we could still
cover case by case.

Another case is transferring fd via unix sockets. But I think in that
case we could also return a socket/port instead of fd. In whatever
srfi that supports unix sockets.
--
Duy