Re: [naviserver-devel] nsproxy API

[Stephen D. <sd...@gm...>]

On 10/6/06, Zoran Vasiljevic <zv...@ar...> 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.