Hi!
J J wrote:
I read on the Wiki that Comanche also forks a new process for each new connection, but from what I could tell it looks like the fork is at the same priority of the server. So what this would mean is if 30 clients connect right after each other, 29 fast clients and one that requires a lot of processing then the clients will connect and be serviced until the 1 long one hits, then the rest have to wait for him to finish.
I haven't looked at the code but I somewhat doubt that. It'd be trivial to fix (see below).
I just looked and yes, AFAICT from a visual short inspection the forked process to serve a new connection does indeed not get any specific prio - it will thus use the same as the TcpService uses, which I think is by default #userBackgroundPriority (30).
Now, I am not sure if this is a problem in practice - perhaps we already have some higher prio process that causes these processes to shuffle around as Andreas describes it.
regards, Göran