2007/4/14, Russ Cox <[EMAIL PROTECTED]>:
There is nothing in Plan 9 like a named socket. There is /srv, which is like named pipes (the difference is that named sockets distinguish multiple connections to them).
That agrees with what I knew. I could not fit the sockets' multiple connections with srv.
If ts were a Plan 9 program, it would present a file tree that could be manipulated to add things to the queue or remove them or check their status, instead of inventing a custom RPC protocol. Then it would post a fd in /srv for 9P service, and you'd mount /srv/ts /mnt/ts and then interact with /mnt/ts via file operations. (Multiple programs can mount /srv/ts because the kernel acts as a multiplexor for 9P services -- the server sees only one 9P conversation.)
That's exactly the kind of answer I was asking for. Thank you. In 'ts', the server does some tasks (has the task list, results.,) and the client does some others. The most important task (fork and exec the queued commad) must be necessarily be run from the client, so all the environment/namespace are kept. What I feel common from the plan9 file servers I've seen by now is that the server does all the processing, and mostly provides the filesystem as an interface to the user. Thus, being the server the process doing all the concerned tasks. Now I still cannot image what kind of files/directories 'ts' should serve to offer a good interface to the user, and how 'enqueuing' should work, getting a nice 'RPC' through that filesystem. I'll think of it, sure. Thanks!
