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