Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch/pull/1#issuecomment-35115035
There's a problem with the waiting queue not being per-language here. This
would block some clients of idle languages if one of the languages happens to
reach its hard limit.
There are basically three approaches I see to fixing this:
1. Remove the per-language limits and just have a global limit. The down
fall here would be fore people that have a mix of both native processes and OS
processes where the weight of each is significantly different (although this is
tempered by the fact that there's no way to configure the limits independently).
2. Turn the queue into something keyed by language as well. A dict of
queues I think would not be good here. I think we'd have to figure out either
something ets based or add in a process for each queue. This would probably be
the least disruptive approach.
3. Change the supervision tree so that the logic is all independent. I
would rename the current couch_proc_manager to something like
couch_proc_lang_manager, and then a new couch_proc_manager would just forward
requests to the proc_lang_manager for the particular language. There's an extra
message pass involved here as well as more overhead in managing the proper
couch_proc_lang_managers in response to the config. (ie, stopping and starting
them as the config changes etc). And in general it'd be a lot more code churn.
I'm torn between 1 and 3. 1 would have the behavior change but I'm having a
hard time convincing myself that's important. 3 would be best for maintaining
the current behavior but with a higher development cost. I can't think of a
good solution for 2 that doesn't make me cringe for one reason or another.
