* [9fans] Porting to plan9 / PF_UNIX @ 2007-04-14 15:34 Lluís Batlle 2007-04-14 15:55 ` W B Hacker ` (3 more replies) 0 siblings, 4 replies; 11+ messages in thread From: Lluís Batlle @ 2007-04-14 15:34 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs I'm the developer of a Unix program that may be useful in plan9, and as an exercise, I'd like it to build in plan9 native. Now, I've written it assuming POSIX (int signals, PF_UNIX available, BSD sockets API, ...). I know more or less some details on plan9 (per process namespaces, network not in a library to link with, notes, ...), but I barely know the 'common' use of the environment. My concern is that I need some local processes to communicate to a local server. Now I use a SOCK_STREAM PF_UNIX in a path in /tmp, where I suppose I can write. I think it's something I can suppose in a POSIX system, but not in plan9. How would you connect local processes (which can be launched at any time) with a central server in plan9? Making that central server serve a filesystem, where the clients write/read? If I knew what's the path I should follow, I could think more easily on a proper API for POSIX and Plan9 for my program. I may not have not worked in plan9 enough to deserve your attention, but I hope a quick answer (even in the form of "man ___") will not take much time. btw, the program I'd like to be able to run in plan9 is http://vicerveza.homeunix.net/~viric/soft/ts/ . I wrote it because I couldn't find anything similar to fit my needs, and maybe in plan9 you already have something quick-and-useful for that purpose, and 'ts' would not make any sense in p9 now. That's also something I'd be glad to know. Thanks in advance, Lluís. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] Porting to plan9 / PF_UNIX 2007-04-14 15:34 [9fans] Porting to plan9 / PF_UNIX Lluís Batlle @ 2007-04-14 15:55 ` W B Hacker 2007-04-14 17:15 ` Lluís Batlle 2007-04-14 16:13 ` Francisco J Ballesteros ` (2 subsequent siblings) 3 siblings, 1 reply; 11+ messages in thread From: W B Hacker @ 2007-04-14 15:55 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Lluís Batlle wrote: > I'm the developer of a Unix program that may be useful in plan9, and > as an exercise, I'd like it to build in plan9 native. > > Now, I've written it assuming POSIX (int signals, PF_UNIX available, > BSD sockets API, ...). I know more or less some details on plan9 (per > process namespaces, network not in a library to link with, notes, > ...), but I barely know the 'common' use of the environment. > > My concern is that I need some local processes to communicate to a > local server. Now I use a SOCK_STREAM PF_UNIX in a path in /tmp, where > I suppose I can write. I think it's something I can suppose in a POSIX > system, but not in plan9. > How would you connect local processes (which can be launched at any > time) with a central server in plan9? Making that central server serve > a filesystem, where the clients write/read? > If I knew what's the path I should follow, I could think more easily > on a proper API for POSIX and Plan9 for my program. > > I may not have not worked in plan9 enough to deserve your attention, > but I hope a quick answer (even in the form of "man ___") will not > take much time. > > btw, the program I'd like to be able to run in plan9 is > http://vicerveza.homeunix.net/~viric/soft/ts/ . I wrote it because I > couldn't find anything similar to fit my needs, and maybe in plan9 you > already have something quick-and-useful for that purpose, and 'ts' > would not make any sense in p9 now. That's also something I'd be glad > to know. > > Thanks in advance, > Lluís. > LLuis, Read the description. Am confused. You connect to s server with a 'terminal' (the client?) The 'client' awaits permission from the server to run the task. - But the task actually runs on the *client*? Shall we presume it is the equivalent of a Plan9 'CPU' then? Or? (i.e. plenty of RAM and CPU-cycles, but short on storage space.) - using the server for scheduling control & spooling the output? AFAIK Plan9 can do many "similar" things already. But I am missing an example or three of what you would actually use this for.. 370-155's aside, there may be sound reason why there is nothing similar... ;-) Bill ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] Porting to plan9 / PF_UNIX 2007-04-14 15:55 ` W B Hacker @ 2007-04-14 17:15 ` Lluís Batlle 2007-04-14 17:28 ` Russ Cox 2007-04-14 19:29 ` W B Hacker 0 siblings, 2 replies; 11+ messages in thread From: Lluís Batlle @ 2007-04-14 17:15 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 2007/4/14, W B Hacker <wbh@conducive.org>: > LLuis, > > Read the description. Am confused. > > You connect to s server with a 'terminal' (the client?) No. The client is also 'ts', as the server. Two processes from the same program, doing different tasks. The server maintains a batch queue of the commands queued by 'ts' clients. > > The 'client' awaits permission from the server to run the task. The server maintains the queue of the tasks to be run (in a simple list). > > - But the task actually runs on the *client*? The task (the queued command) will be forked and execed from the client, once it received the server message allowing the task to be run (so, all previous tasks in the queue were accomplished) > > Shall we presume it is the equivalent of a Plan9 'CPU' then? Or? I don't think it's any similar at all. > > (i.e. plenty of RAM and CPU-cycles, but short on storage space.) > > - using the server for scheduling control & spooling the output? The server knows to what file the output is stored. And it 'spools' the tasks. I wouldn't use the verb 'schedule' for spooling. > > AFAIK Plan9 can do many "similar" things already. > > But I am missing an example or three of what you would actually use this for.. > 370-155's aside, there may be sound reason why there is nothing similar... What are 370 and 155? Maybe you could look at the manpage of 'ts' for more information. Regards, Lluís. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] Porting to plan9 / PF_UNIX 2007-04-14 17:15 ` Lluís Batlle @ 2007-04-14 17:28 ` Russ Cox 2007-04-14 17:44 ` Lluís Batlle 2007-04-14 19:29 ` W B Hacker 1 sibling, 1 reply; 11+ messages in thread From: Russ Cox @ 2007-04-14 17:28 UTC (permalink / raw) To: 9fans 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). 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.) Russ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] Porting to plan9 / PF_UNIX 2007-04-14 17:28 ` Russ Cox @ 2007-04-14 17:44 ` Lluís Batlle 2007-04-14 21:17 ` ron minnich 0 siblings, 1 reply; 11+ messages in thread From: Lluís Batlle @ 2007-04-14 17:44 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 2007/4/14, Russ Cox <rsc@swtch.com>: > 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! ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] Porting to plan9 / PF_UNIX 2007-04-14 17:44 ` Lluís Batlle @ 2007-04-14 21:17 ` ron minnich 2007-04-15 17:41 ` Lluís Batlle 0 siblings, 1 reply; 11+ messages in thread From: ron minnich @ 2007-04-14 21:17 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 4/14/07, Lluís Batlle <viriketo@gmail.com> wrote: > > 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. Liuis, I did something like this for the 9grid, for taskbags. I've also written similar tools for Unix over the years, so I think I see what you are up to. It's not identical to ts, just similar in nature. The server I wrote for Plan 9 was originally a port of the TNT work described here: http://arxiv.org/PS_cache/astro-ph/pdf/9912/9912134v1.pdf. The TNT server maintained task state describing work to be done, and mutiplexed that work to clients. One of the nice things about TNT, not mentioned in the paper, is that it supports "third party" or middlemen clients, i.e. clients can become servers and grab a bunch of tasks to be handed out. This distribution can be important if you have enough nodes, and turn tasks over very frequently. Also, of course, clients can put new work back into the bag of tasks. The work to be done was communicated to the server to/from clients via RPC (SunRPC). So, I began to do a straight conversion of this Unix socket-based server to Plan 9; about 10 minutes into the job, I realized I was not thinking about the problem correctly. I thought about what I would do if starting from scratch, on Plan 9. Plan 9 makes writing servers so easy that I went that route. I dumped the RPC-based model and created a server that represented the state of the work as directories and files. Basically, the server has three directories, questions, working, and answers. You put questions into the questions directory by opening and writing a file. To pass your 'namespace', you could do an ns command into the questions file you created, then put the work in as a set of commands or rc script into that file. Each new piece of work is a new file. Clients start working by opening a questions file. Once a client has opened a questions file, subsequent 'ls' commands will show that file in the working directory, not the questions directory. To see what work is being done, you ls the working directory. Once a process is done, it closes the file; at that point, the file will appear in the answers directory, IF it has been written to. If the file was not written to, it reappears in the questions directory (this is to handle the case of clients that die). To see the answers to date, ls answers or cat answers/*. If you want programs to find out when work is completed,you could extend the server by having it create a 'status' file at the top level; programs can read that and block on it, and your server can distribute status info to as jobs are done. With this new Plan 9 server, I was able to do distributed computation entirely with shell scripts. One old problem with task bags related to multiple users. What if more than one user writes the task bag? This has been solved in complex ways on Unixen, with authentication happening on the server so that only the 'right' people get to the socket. This is solved trivially in Plan 9 -- each user, needing this service, starts a task bag server -- problem solved. The beauty of a server is that you can stop thinking in terms of RPC! The "files" create a structure that is normally done in RPC. So, on Plan 9, try to avoid falling into old Unix patterns. If you start thinking in terms of a 'server' socket, and not a 9p server, and if you start writing RPC code, the odds are good that you are not approaching the problem correctly. I ported a few HPC computations to my taskbag server; it was pretty trivial. I *think* I left the code on sources (man 9fs to see what this statement means) in the 9grid directory; you can look. BTW, this sort of 'file-based' task bag idea has been done to death as well, usually on NFS and with a huge boatload of scripts to go with it. One system I saw, for MPEG encoding, had a 100-page (or so) script to use NFS files for holding tasks. 99 pages were for dealing with the problems that come with using NFS for this purpose ... not being able to guarantee exclusive create, open, and remove makes these things messy. It's not just the idea of using files to describe work that is so effective; it's the fact that the operations on the files are under control of your server, and hence they're not really files, but a representation of the work, shown to you as files. This disctinction is very important. It's why a Plan 9 task bag server can work, and the NFS-based task bag servers fail, and fail badly. It's nice to have you involved in Plan 9; welcome aboard. Don't hesitate to ask questions. It will be nice to see what you create. thanks ron ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] Porting to plan9 / PF_UNIX 2007-04-14 21:17 ` ron minnich @ 2007-04-15 17:41 ` Lluís Batlle 0 siblings, 0 replies; 11+ messages in thread From: Lluís Batlle @ 2007-04-15 17:41 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 2007/4/14, ron minnich <rminnich@gmail.com>: > On 4/14/07, Lluís Batlle <viriketo@gmail.com> wrote: > > > > > 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. > > > The server I wrote for Plan 9 was originally a port of the TNT work > described here: > http://arxiv.org/PS_cache/astro-ph/pdf/9912/9912134v1.pdf. The TNT > server maintained task state describing work to be done, and > mutiplexed that work to clients. One of the nice things about TNT, not > mentioned in the paper, is that it supports "third party" or middlemen > clients, i.e. clients can become servers and grab a bunch of tasks to > be handed out. This distribution can be important if you have enough > nodes, and turn tasks over very frequently. Also, of course, clients > can put new work back into the bag of tasks. The work to be done was > communicated to the server to/from clients via RPC (SunRPC). So, I > began to do a straight conversion of this Unix socket-based server to > Plan 9; about 10 minutes into the job, I realized I was not thinking > about the problem correctly. I was almost certain that I should rethink the whole program again, and although I may use some kind of RPC in unix (for avoiding linking against p9p libs), I should be able to provide an API independant from RPC or file servers. But having some code written in that direction would make me more sure of my words. :) > > I thought about what I would do if starting from scratch, on Plan 9. > Plan 9 makes writing servers so easy that I went that route. I dumped > the RPC-based model and created a server that represented the state of > the work as directories and files. Basically, the server has three > directories, questions, working, and answers. You put questions into > the questions directory by opening and writing a file. To pass your > ..... I'd like to know what kind of file the "task submitter" should open. Did you have several names in the questions directory, and each submitter took one at random? It should be a name not colliding with others in working or answers... Or maybe the submitter opened a file with _any_ name (altough no 'ls' would show it in questions), and that was created with the same name in working? > > One old problem with task bags related to multiple users. What if more > than one user writes the task bag? This has been solved in complex > ways on Unixen, with authentication happening on the server so that > only the 'right' people get to the socket. This is solved trivially in > Plan 9 -- each user, needing this service, starts a task bag server -- > problem solved. Also in my 'ts' each user has (in general) its own server. It depends on the socket path they use. On agreement among users, they can use a common socket with proper unix socket permissions in the filesystem. > > The beauty of a server is that you can stop thinking in terms of RPC! > The "files" create a structure that is normally done in RPC. So, on > Plan 9, try to avoid falling into old Unix patterns. If you start > thinking in terms of a 'server' socket, and not a 9p server, and if > you start writing RPC code, the odds are good that you are not > approaching the problem correctly. I agree. But RPC may be as awful as lazy I am, and the file structure requires more thinking to find a nice solution - it will be probably published to users :) > > I ported a few HPC computations to my taskbag server; it was pretty > trivial. I *think* I left the code on sources (man 9fs to see what > this statement means) in the 9grid directory; you can look. I looked at /n/sources/9grid, but I could only find some code for xcpu there. Nothing named 'task bags' at first glance. > > BTW, this sort of 'file-based' task bag idea has been done to death as > well, usually on NFS and with a huge boatload of scripts to go with > it. One system I saw, for MPEG encoding, had a 100-page (or so) script > to use NFS files for holding tasks. 99 pages were for dealing with the > problems that come with using NFS for this purpose ... not being able > to guarantee exclusive create, open, and remove makes these things > messy. Well, my purpose on ts has never been multiuser queues for different computers. I thought it for the case a user knows the multitasking-limits of the resources of a single computer. Using hard disk heavily in two applications may slowdown both. Using at once two applications each requiring the amount of physical ram in the computer, may also slow/bring down the system. That's what ts was meant for. > > It's not just the idea of using files to describe work that is so > effective; it's the fact that the operations on the files are under > control of your server, and hence they're not really files, but a > representation of the work, shown to you as files. This disctinction > is very important. It's why a Plan 9 task bag server can work, and the > NFS-based task bag servers fail, and fail badly. Sure. I barely can believe someone tried such a thing over NFS. > > It's nice to have you involved in Plan 9; welcome aboard. Don't > hesitate to ask questions. It will be nice to see what you create. Having seen code in the operating system, read some works from Pike and Kernighan, watched the discussions in this list from a long time, it'd be a honor contributing a bit to the OS. But I cannot guarantee code in short term. My university project is entirely for another computing field and I should work on it, my job, and other studies grab my time in own elected priority. I can't say that I _need_ ts in plan9 (I mostly use p9p and not the OS). But it's a direction I'd like to move on. I'll also consider the nice and simple idea from John Stalker. Thank you for your inspiring and couraging messages, Lluís ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] Porting to plan9 / PF_UNIX 2007-04-14 17:15 ` Lluís Batlle 2007-04-14 17:28 ` Russ Cox @ 2007-04-14 19:29 ` W B Hacker 1 sibling, 0 replies; 11+ messages in thread From: W B Hacker @ 2007-04-14 19:29 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Lluís Batlle wrote: > 2007/4/14, W B Hacker <wbh@conducive.org>: >> LLuis, *snip* >> But I am missing an example or three of what you would actually use >> this for.. >> 370-155's aside, there may be sound reason why there is nothing >> similar... > What are 370 and 155? One of a family of IBM systems for turning batch processing into cash. Quite a lot of it from 1964 to the present day. > > Maybe you could look at the manpage of 'ts' for more information. > You describe a method, but not a specific application that benefits from it. Some - pehaps *all* of what you need to accomplish should be 'doable' within the existing Plan9 toolset - just not in quite the same manner as in either the Unix or '370 compatible' worlds.. Bill ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] Porting to plan9 / PF_UNIX 2007-04-14 15:34 [9fans] Porting to plan9 / PF_UNIX Lluís Batlle 2007-04-14 15:55 ` W B Hacker @ 2007-04-14 16:13 ` Francisco J Ballesteros 2007-04-14 17:01 ` Uriel 2007-04-14 21:28 ` John Stalker 3 siblings, 0 replies; 11+ messages in thread From: Francisco J Ballesteros @ 2007-04-14 16:13 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs If you want a program to serve something for others, there are several ways. One way would be to write a file server, and register with srv(3) one end of a pipe that others could mount. There are plenty of examples in /sys/src/cmd. I'd suggest to go over the manual seeking for programs that might do something similar to what you want, and then reading their code. hth On 4/14/07, Lluís Batlle <viriketo@gmail.com> wrote: > I'm the developer of a Unix program that may be useful in plan9, and > as an exercise, I'd like it to build in plan9 native. > > Now, I've written it assuming POSIX (int signals, PF_UNIX available, > BSD sockets API, ...). I know more or less some details on plan9 (per > process namespaces, network not in a library to link with, notes, > ...), but I barely know the 'common' use of the environment. > > My concern is that I need some local processes to communicate to a > local server. Now I use a SOCK_STREAM PF_UNIX in a path in /tmp, where > I suppose I can write. I think it's something I can suppose in a POSIX > system, but not in plan9. > How would you connect local processes (which can be launched at any > time) with a central server in plan9? Making that central server serve > a filesystem, where the clients write/read? > If I knew what's the path I should follow, I could think more easily > on a proper API for POSIX and Plan9 for my program. > > I may not have not worked in plan9 enough to deserve your attention, > but I hope a quick answer (even in the form of "man ___") will not > take much time. > > btw, the program I'd like to be able to run in plan9 is > http://vicerveza.homeunix.net/~viric/soft/ts/ . I wrote it because I > couldn't find anything similar to fit my needs, and maybe in plan9 you > already have something quick-and-useful for that purpose, and 'ts' > would not make any sense in p9 now. That's also something I'd be glad > to know. > > Thanks in advance, > Lluís. > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] Porting to plan9 / PF_UNIX 2007-04-14 15:34 [9fans] Porting to plan9 / PF_UNIX Lluís Batlle 2007-04-14 15:55 ` W B Hacker 2007-04-14 16:13 ` Francisco J Ballesteros @ 2007-04-14 17:01 ` Uriel 2007-04-14 21:28 ` John Stalker 3 siblings, 0 replies; 11+ messages in thread From: Uriel @ 2007-04-14 17:01 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs You might want to look at cpu(1) (for Plan 9) and http;//www.xcpu.org (for Plan 9 and other systems.) And there is also taskfs by Kenji Arisawa, I think the latest version of you can find in /n/sources/contrib/arisawa/grid.tgz (Kenji, would be nice if you added an INDEX file to your sources/contrib dir) And finally taskbag by Nashi of which the only version I can find is in http://www.tip9ug.jp/who/nashi/9grid/taskbag.tgz Nashi: *please*, could you put that stuff in sources/contrib like everyone else? It is already hard enough to find things as it is. And as nemo pointed out, srv(1) is probably what you were asking for. Best wishes uriel On 4/14/07, Lluís Batlle <viriketo@gmail.com> wrote: > I'm the developer of a Unix program that may be useful in plan9, and > as an exercise, I'd like it to build in plan9 native. > > Now, I've written it assuming POSIX (int signals, PF_UNIX available, > BSD sockets API, ...). I know more or less some details on plan9 (per > process namespaces, network not in a library to link with, notes, > ...), but I barely know the 'common' use of the environment. > > My concern is that I need some local processes to communicate to a > local server. Now I use a SOCK_STREAM PF_UNIX in a path in /tmp, where > I suppose I can write. I think it's something I can suppose in a POSIX > system, but not in plan9. > How would you connect local processes (which can be launched at any > time) with a central server in plan9? Making that central server serve > a filesystem, where the clients write/read? > If I knew what's the path I should follow, I could think more easily > on a proper API for POSIX and Plan9 for my program. > > I may not have not worked in plan9 enough to deserve your attention, > but I hope a quick answer (even in the form of "man ___") will not > take much time. > > btw, the program I'd like to be able to run in plan9 is > http://vicerveza.homeunix.net/~viric/soft/ts/ . I wrote it because I > couldn't find anything similar to fit my needs, and maybe in plan9 you > already have something quick-and-useful for that purpose, and 'ts' > would not make any sense in p9 now. That's also something I'd be glad > to know. > > Thanks in advance, > Lluís. > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] Porting to plan9 / PF_UNIX 2007-04-14 15:34 [9fans] Porting to plan9 / PF_UNIX Lluís Batlle ` (2 preceding siblings ...) 2007-04-14 17:01 ` Uriel @ 2007-04-14 21:28 ` John Stalker 3 siblings, 0 replies; 11+ messages in thread From: John Stalker @ 2007-04-14 21:28 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs I am not sure how I would use this, so my ideas of an appropriate interface are probably a bit off. For what it's worth, I would imagine a file system like the one mounted on /proc. One subdirectory per process. The files in the subdirectory would vary a bit depending on whether the job is finished, running or queued. In addition to the numbered directories there would be a special directory next, containing only the args file. Writing to /queue/next/args would create a job, which would then appear as a numbered directory like all the others. Feel free to ignore any of this if it doesn't fit your idea of what the spooler is for. John ps Since I started writing this, Ron's answer has appeared. It may well be a better idea, since he has actually implemented it and therefore knows where the pitfalls are. > I'm the developer of a Unix program that may be useful in plan9, and > as an exercise, I'd like it to build in plan9 native. > > Now, I've written it assuming POSIX (int signals, PF_UNIX available, > BSD sockets API, ...). I know more or less some details on plan9 (per > process namespaces, network not in a library to link with, notes, > ...), but I barely know the 'common' use of the environment. > > My concern is that I need some local processes to communicate to a > local server. Now I use a SOCK_STREAM PF_UNIX in a path in /tmp, where > I suppose I can write. I think it's something I can suppose in a POSIX > system, but not in plan9. > How would you connect local processes (which can be launched at any > time) with a central server in plan9? Making that central server serve > a filesystem, where the clients write/read? > If I knew what's the path I should follow, I could think more easily > on a proper API for POSIX and Plan9 for my program. > > I may not have not worked in plan9 enough to deserve your attention, > but I hope a quick answer (even in the form of "man ___") will not > take much time. > > btw, the program I'd like to be able to run in plan9 is > http://vicerveza.homeunix.net/~viric/soft/ts/ . I wrote it because I > couldn't find anything similar to fit my needs, and maybe in plan9 you > already have something quick-and-useful for that purpose, and 'ts' > would not make any sense in p9 now. That's also something I'd be glad > to know. > > Thanks in advance, > Llu=EDs. -- John Stalker School of Mathematics Trinity College Dublin tel +353 1 896 1983 fax +353 1 896 2282 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2007-04-15 17:41 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-04-14 15:34 [9fans] Porting to plan9 / PF_UNIX Lluís Batlle 2007-04-14 15:55 ` W B Hacker 2007-04-14 17:15 ` Lluís Batlle 2007-04-14 17:28 ` Russ Cox 2007-04-14 17:44 ` Lluís Batlle 2007-04-14 21:17 ` ron minnich 2007-04-15 17:41 ` Lluís Batlle 2007-04-14 19:29 ` W B Hacker 2007-04-14 16:13 ` Francisco J Ballesteros 2007-04-14 17:01 ` Uriel 2007-04-14 21:28 ` John Stalker
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).