http://qs1969.pair.com?node_id=123729


in reply to bidirectional IPC (Linux)

From your description, it sounds as though pipes would be fine. You can read them when you want and you can have many pipes: one to each child. One parent can talk to each child with its own pipe. Why do you think "but as every child does this, the connection has to be between one end and many ends"? Do you need to send one message to all the clients at once? Are you trying to send a message from the parent and let a single client pick it up?

I'm not sure exactly what you need to do, but you can thread the server (that's what a lot of chat servers do) or you can use select(the four argument one) to decide when you need to read from a child.

If you give us some more information, or maybe an example of what you've tried, we might be able to be of more help.

HTH, --traveler

Replies are listed 'Best First'.
Re: Re: bidirectional IPC (Linux)
by Mirage (Sexton) on Nov 07, 2001 at 21:25 UTC
    >...can read them when you want and you can have many pipes: one to each child.

    but I have to have two pipes to each child, don't I?

    >Do you need to send one message to all the clients at once?

    thats right, this wont work...

    >I'm not sure exactly what you need to do, but you can thread the server (that's what a lot of chat servers do)
    >or you can use select(the four argument one) to decide when you need to read from a child.

    hmm threads will not be present in their actual form
    in future releases of perl, as I have extracted from man
    thread, so i think thats not the best way to do it.
    Select is then a method without fork, but I haven't
    understood it completely, what does the Select do, it
    determines from which socket 'data comes in', and then
    reads it?

    Thanks
[reply]
      but I have to have two pipes to each child, don't I?

      Yes. If you want to follow the rules and if you are sending data bidirectionally. Or you can use a socket. Sockets are bidirectional and work very much like pipes once established.

      thats right, this wont work...

      I'm not sure what you mean by this.

      Select is then a method without fork, but I haven't understood it completely, what does the Select do, it determines from which socket 'data comes in', and then reads it?

      No. select tells you when a filehandle is ready for reading or writing or when it has an error condition. You need to do the I/O yourself. It can be used with or without fork.

      While the implementation of threads, and maybe the syntax may change, using threads may still be your best bet.

      HTH, --traveler

[reply]
[d/l]
        >I'm not sure what you mean by this.

        it simply means youre right, i can't send to all clients at
        once, or better i dont want to because it mostly senseless.

        >No. select tells you when a filehandle is ready for reading or writing or when it has an error condition. You need to do the I/O yourself. It
        >can be used with or without fork.

        this means, I still have to fork, and then do the IPC stuff, right?
        Maybe i really should consider threads, because i think
        using two pipes, with two extra child for each child,
        i have too much childs at the, especially if the amount of
        connections is on a normal level of 20, i would have 60
        processes, way too much...

        Thanks so far
[reply]

In Section Seekers of Perl Wisdom