Re: [naviserver-devel] nsproxy API

[Zoran V. <zv...@ar...>]

On 03.10.2006, at 00:05, Stephen Deasey wrote:


>
> I'm not sure how much real code sharing there would be between a
> combined job/proxy module. The back ends are different, processes can
> have more limits, the focus on parallelism versus isolation...

Apart from the "unified" API there would be no other "benefits".
Code sharing would be rather minimal. It would perhaps be easier
to use since you do not need to remember just-another-api.
But I'm perfectly happy with both. We would have to find a consensus
on that and I'll do it.

>
>
>>       The oher thing, I do not like the "default" pool. I think  
>> the pool
>>       (being the place to put common things shared across all slaves)
>>       should be given explicitly.
>
>
> It would allow a simple 'set' command to configure parameters, like
> the limits stuff.  The proxy pool 'default' already exists, and then
> you adjust it if you need to.
>

Hmmm... set "what"?

> With a default pool, we could alias the Tcl 'exec' command to run in a
> proxy pool.

This is the good reason.

>
> Although you can configure the binary to bootstrap the proxy
> processes, that's probably going to be rare. In fact most situations
> would probably be covered by a sane, default setup.

True.

>
> If there's no default pool, then all user code which uses nsproxy will
> create it's own pool. With multiple pools there may be some which run
> out of resources while others have spare -- the pools are a hard
> partitioning of resources.

True. But pools are there because of the different:

   timers
   initialization scripts

I use the nsproxy in 2 places in the code now. Both require different
init scripts. One requires indefinite timer (like simple exec) and the
one "can" kill the process if the computation went more than 30 seconds.

It is true what you say about partitioning of resources, though...
Still, when I have to choose, I'd rather opt for explicit pool
rather than having a "default" pool. I'd really leave this to the
programmer. The programmer can do trivial Tcl wrapper to redirect
Tcl exec to the proxy if needed.

>
>
>>    b. If we go that far then ns_exec_xxx is also not a suitable  
>> name as
>>       we are not exec'ing anything really.
>
>
> A common reason to use the proxy module is to isolate calls to the Tcl
> exec command. The proxies must also execute an external process
> (default nsproxy).  Just trying to get away from 'proxy'. Maybe
> something with 'ext', for 'external' in the name?

To summarize. What you object is:

   a. handle management (should work without handles)
   b. name of the module (should not be proxy)
   c. invent default pool
   d. ?


For a:
I understand the syntactical need, but this is how I see that from
the practical side. By having a handle, I can run "things" in the
proxy (lets call it slave process from now on) one after another with
a possible "state" between the runs. This might sometimes be needed.
If I hide the handle, how could I force my two or three consecutive
operations to be executed in the same slave?

For b.
I do not care how we call it. We can call it ns_cocacola if you like.
The name contest is open...

For c.
I'd rather stick to explicit pool naming. I'd leave this "default"
to the programmer. The programmer might do something like
(not 100% right but serves the illustration purpose):

    ns_proxy config default
    rename ::exec tcl::exec
    proc ::exec args {
        ns_proxy eval default $args
    }

This covers overloading of Tcl exec command. If you can convince me
that there are other benefits of having the default pool I can
think about them. I just do not see any at this point.