>>>> 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 mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
