Well, I've been through the perldoc and it seems to mostly focus on the normal forking server model. Having a separate process for every client is all well and nice for most things but I have a slightly different situation.
Imagine you are building a simple chat. A thousand users connecting with telnet or something primitive like that. Everything one client sends is bounced back to all connected clients. In this case, is it really a good idea to have a separate process for every client? I can't help but think it would be easier to have one single process with a list of sockets. That way you could read from all clients in turn (non-blocking) and in the case of finding a message waiting, simply print it to all the sockets.
This does however give me a problem. In order to connect new clients I must do an accept() every now and then. That is blocking - which is bad in this cas since it will block the only process until someone connects.
So, am I barking up the wrong tree here? How would you people solve something like this? Will I be forced to muck about with threads, having one that looks for clients and one that does the chatting?
-- Curious
In reply to Non-forking server? by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |