On 10/6/06, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
On 06.10.2006, at 21:25, Stephen Deasey wrote:
>
> But what I'm wondering is, why you need to do this with proxy slaves?
> It seems like they don't have the same state problem that a series of
> database statements do.
>
> It's possible to send multiple Tcl commands to a single proxy slave at
> the same time:
>
> ns_proxy eval {
> set f [do_foo ...]
> set b [do_bar ...]
> return [list $f $b]
> }
>
> (You can't do that with databases because they often forbid using a
> statement separating semicolon when using prepared statements and/or
> bind variables. But Tcl doesn't have that restriction.)
I do not need it. As, as you say, I can simply send all of them
in one script. That's trivial of course.
I give you another reason pro-handle: I'd like to allocate
the handle in order to have it always (for a longer time)
available. I "reserve" it, so to speak. If I can't do that
than my code is less "predictive" in terms that I might wait
potentially for a long time to get the chance to do something
as all proxies might be doing something else. Understand?
In this case, wouldn't you just size the pool so that there was always
a free handle?
If the pool doesn't have enough handles, and you do hang on to handles
in threads indefinitely, then you've basically got a first come, first
served system. The threads which ask first will get handles and the
rest will be permanently disappointed...
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.
