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

>...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

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

From man IO::Select:

Here is a short example which shows how `IO::Select' could be used to write a server which communicates with several sockets while also listening for more connections on a listen socket

           use IO::Select;
           use IO::Socket;

           $lsn = new IO::Socket::INET(Listen => 1, LocalPort => 8080)
+;
           $sel = new IO::Select( $lsn );

           while(@ready = $sel->can_read) {
               foreach $fh (@ready) {
                   if($fh == $lsn) {
                       # Create a new socket
                       $new = $lsn->accept;
                       $sel->add($new);
                   }
                   else {
                       # Process socket

                       # Maybe we have finished with the socket
                       $sel->remove($fh);
                       $fh->close;
                   }
               }
           }
[download]

After Compline,
Zaxo

____________________
Jeremy
I didn't believe in evil until I dated it.

thanks, I will look it up later and reply or msg if I have problems(hopefully this is what I was looking for)

After looking at your module i think its of no real use
for me, nor for any other real server application, or
forking application, because having one one port for each
process is too much, and why don't you use unix-domain-sockets?

Couple of responses:
• I was under the impression that every network socket has an associated domain socket (not that I ever checked).
• You said you had already tried UDS
• Exactly how many processes were you planning to use? There are 64000 possible sockets which means that you can have 32000 forked processes before you run out of sockets.
• If you are trying to write code for a machine that can handle 32000 processes, grab the Apache source code since that is the canonical example of a really good forking server. And then give me an account on your machine :)
• If you read the pod, my goal was portable reliable forking IPC.
• I am currently reworking the architecture so that you can drop in any transport layer that you want to use - I have a demo using SysV message queues, and I can't wait to hear your comments on that one.
• The basic architecture of my code is useful for a preforking server, regardless of the transport layer. For someone who doesn't even know what select does, you seem to be pretty good at pointing out why code you don't understand is unsuitable for your purpose.

____________________
Jeremy
I didn't believe in evil until I dated it.