On 06.10.2006, at 22:32, Stephen Deasey wrote:
Or, maybe you need a special pool for special threads, and a default
pool for generic threads. If there are only a couple of special
threads then the pool can be small -- you don't need to size the pool
according to the many generic threads just to make sure there's always
one left over for a special thread.
So, if I can read between the lines, you say we should get
rid of the handles in ns_whateverwenamethething ? Completely?
Irreversibly? Just plain trash handles altogether and always
lock pool, get slave, send command, wait for result, read result,
lock pool, put slave back.
You loose "reservation" but gain "no starvation". This is a trade-off.
In such situations it is more oportune to have both. So you can
do it with or w/o handles. You can "reserve" and run your commands in
the handle, or you can run directly, w/o handle. This can all be the
part of the API. I simply hate NOT to be able to reserve a process,
open a file in it and use that descriptor for long time. I'd easily
imagine how I can profit from that and trashing handles altogether
just cuts me from this capability.
OK. So far I can go. I could imagine an API without explicit
handle usage. I can't however imagine scratching them (handles)
altogether.
The default pool is still giving me headaches.
How would you configure default pool options?
