Matt Benson wrote:
--- Steve Loughran <[EMAIL PROTECTED]> wrote:
-Matt
Interesting design. I would have done a <namedpipe
id="" /> datatype
that did the synchronisation; producers and
consumers would sync by
choice of pipename.
That could work, for isolation. How would you specify
the roles of producer/consumer? Not that it matters
too much, because:
It depends on the role. If you ask a named pipe for an input stream, you
get an input stream, become a reader and block until there is a writer.
If you ask one for an output stream, you get an output stream and block
once the buffer is full. If >1 thing wants to be a reader or writer,
signal a fault. (in unix you can have multiple readers or writers, but I
dont want to complicate close() semantics with new reference counted
closers)
But like you say, the problem
becomes process
co-ordination; handling failures and propagating
them gracefully, or
just how to keep processes around until their
consumer/producer was
there. This is the stuff we normally delegate to the
OS, or, for
distrubution, to some message queue. Though named
pipes work across
clusters, at least on the apollo and hpux cluster
systems.
This grows beyond my level of understanding. :)
ahh, go and build it, you will soon learn. I've used unix named pipes in
the past, and think they are a very cool form of IPC; like a socket but
with better decoupling of produce/consume.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
