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.
