Re: [RFC] inetd(8) changes proposal

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>>>> So I added a new file descriptor type (well, semi-new; they're
>>>> DTYPE_MISC) and a new syscall (pidconn) [...]
>>> In this area (as others, in fact), the Plan9 solution is
>>> [/proc/$PID/ctl]
>> That is unidirectional communication.  pidconn is bidirectional.
>> Aside from that, how does the process (a) notice that this has been
>> done and (b) get the string ($cmd in the above) to act on it?
> Controling the process can be made by writing to the "ctl" file (this
> does what some Unix signals do).

Okay, so it's not really comparable to pidconn.

> And if bi-directional IPC is wanted, it can be done at user-level
> with the plumber that allows to "receive, examine, rewrite and
> dispatch messages between programs" as long as the program allows to
> be plumbed (prepared to read and write from conventionally named file
> in the namespace).  (It does multiplexing too; it is not only 1<->1.)

> In fact, one can do the same thing probably with Unix.

One can do similar things.  I could have, for example, decided that I
would use AF_LOCAL sockets in /IPC/ with names matching participating
process's PIDs.  Or I could have used AF_INET6 sockets in host-local
space (I think there's some host-local space defined).  Or probably
various other alternatives.

However, none of those was a good-enough match to the semantics I
wanted for me to be content with it.  (Most particularly, none of them
have anything stopping process X from using the endpoint appropriate to
process Y and none of them seamlessly handle forking processes.)

It's possible that Plan 9 has something else that would work better.
But switching to Plan 9 just to get this was a _much_ higher cost than
just implementing pidconn() - if it had occurred to me to think Plan 9
might have had something suitable, which it didn't.

> But the concept of having well-known file names to communicate with a
> process is appealing and to not have to set the communication
> channels in every program but just to prepare to use them if the
> program wants too, is a bonus.

Except for the "file names" part of that, I agree.  pidconn does
require that programs interested in accepting connections do need to do
a little preparation; I could have implicitly created a listening
endpoint for every process, but I have no good answer to the question
of what happens if you try to connect to a process that isn't
interested in such connections.  Either that question needs answering
or participating processes have to declare their interest in such
connections _somehow_.  I chose the latter.

I might have been able to do it using mount_portal.  I haven't
investigated that; perhaps I should have.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B