Re: [naviserver-devel] nsproxy API

[Vlad S. <vl...@cr...>]

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
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> 

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/