Alas, I assumed that the functionality would mirror the original
design from whence it was stolen. In Plan 9 any program can access
the tcp/ip stack or any other networking protocol in just exactly that
way. Of course, Plan 9 is extraordinarily different under the hood,
so it's very easy to do it there. However, people constantly port
Plan 9 user space features, especially the nice programming tools, to
Linux, including the /proc filesystem, as well as the 9p kernel module
(which, btw, in tandem allow an extremely novel approach to monitoring
system performance across networks, think of 9p as an extremely
general purpose, byte-wise rather than blockwise filesystem, except
you can expose an object as a 'file' and read and write to it, giving
it arbitrary functionality for what writing and reading the file do.)
In any case, it would be fairly trivial to write a program which
accepted several other programs as arguments, linked them together
using multiple calls to pipe, and fork, then execing the name
programs. Such a program would require only a few lines of C. Pipes
being unidirectional does not prevent me from doing:
a2b = pipe()
b2c = pipe()
c2a = pipe()
fork()
if( processA)
do
read_on( c2a)
write_on( a2b)
exec( a)
done
fork()
if( processB)
do
read_on( a2b)
write_on( b2c)
exec( b)
done
# this must be processC
read_on( b2c)
write_on( c2a)
exec( c)
the actual read_on and write_on functions involve closing one of the
two file descriptors for the given pipe in the given process space,
exec is actually a suite of calls, see man execvp for the details.
You will also want to read the fork man page, the pipe info is very
straight-forward however, and you should only need the synopsis. It
passes back 2 integers one is an fd to read, the other to write, close
the one you won't be using for the given pipe.
Voila, 3-way IPC
if you want, you could very easily do this itratively and circularly
link as many processes as you'd like (within your system's limits)
alternatively, with a bit more cleverness you could parse a rules file
and get quite complex piping behaviour
You may ALSO want to examine the plumber (pipes on steroids!!) utility
in plan9port (http://swtch.com/plan9port/) which will allow you to
write rules files that look a bit like awk programs. They are
basically of the format: <pattern>: <rule> where pattern is a way of
identifying some type of 'plumbed' message, and a rule for where to
send it. Then each program simply sends its output to plumber, and
reads its input from a special file plumber supplies. Then every
message gets magically routed to the process that needs it. Hey
presto!
Erik Johnson
On Sun, Mar 1, 2009 at 11:48 AM, Richard Troth <[email protected]> wrote:
> John McKown wrote:
>> You can't. It is like netcat - communications is unidirectional.
> ...
>> What you'd like would be more like a bidirectional pipe,
>> if there were such a thing. IIRC, "pipes" in UNIX are unidirectional.
> ...
>> Perhaps a <> symbol?
>>
>> cmd1 <> cmd2
>
>
> Time for a little duct tape for those leaky garden hoses, eh?
> What we need is he-man pipelining akin to CMS Pipelines, like
>
>
> pipe L: cmd1 | cmd2 | L:
>
>
> which clearly lets cmd1 feed cmd2 and vice versa,
> but with more syntactic clarity than a "<>" symbol.
>
>
> -- Rick;
>
> ----------------------------------------------------------------------
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO LINUX-390 or visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
>
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
