Re: [naviserver-devel] nsproxy API

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

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 ?