I like the idea of extending ns_job to handle processes, this way when i
create queue i define what kind it is: threads or processes and then use
it same way, no need in eval command, ns_job queue submites script to be
evaluated to the next avail thread/process
Zoran Vasiljevic wrote:
On 18.09.2006, at 20:55, Stephen Deasey wrote:
API:
result ns_exec_eval ?-pool p? ?-timeout t? script
Id ns_exec_queue ?-detached? ?-pool p? ?-timeout t? script
ns_exec_wait ?-timeout t? Id ?Id ...?
ns_exec_cancel
ns_exec_set ?-opt val ...? pool
ns_exec_stats pool
Example:
set result [ns_exec_eval {
set x y
exec /bin/blah $x
}]
Notes:
Create pool 'default' on startup.
Reuse identical processes (same binary, ulimits, etc.) among
pools, in
the same way that threads are shared globally among ns_job
queues.
'maxexecs' parameter, after which processes exit and are
respawned.
First impression:
a. I'd rather use ns_cmdtobenamed queue pool ...
ns_cmdtobenamed eval pool ...
Two things here: ns_exec_command I do not like. The "Tcl" way
would
be actually to use a namespace to encapsulate all commands but
that
would break the current style.
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.
b. If we go that far then ns_exec_xxx is also not a suitable name as
we are not exec'ing anything really.
But lets go two steps back...
You say you wanted to get ns_job and ns_proxy together. You also say
that this is not feasible because of the "eval" command.
Why?
The ns_job could be expanded easily to integrate the "eval" command,
but it would not make much sense (i.e. practical use). OTOH, the
ns_proxy eval has much sense (i.e. practical use). Given that, in my
opinion, [ns_job eval] would not harm anybody, why _not_ integrating
both?
Instead of aueue of threads, youd create queue of processes. Most (if
not all) of other ns_job commands will just be "blind" in terms of
threads vs. processes. Each process would actually be the nsd itself
but using alternate Ns_Main function. It would load the libnsd.so, read
the same (or alternate) configuration file, etc. pp.
This way the API question is solved. The work to be done is pretty clear
(rewrite ns_job internals to allow handling of processes in addition to
threads).
Is there a very good reason why not going that way instead of
maintaining the proxy module ?
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
--
Vlad Seryakov
571 262-8608 office
[EMAIL PROTECTED]
http://www.crystalballinc.com/vlad/
