On 07.10.2006, at 00:39, Stephen Deasey wrote:
But the call may take longer than the caller budgeted for, due to all
the hidden timeouts, which are additive.
True.
So the callers time budget is 5 seconds, and that's what they pass to
-evaltimeout. But by default both the sendtimeout and
On 10/7/06, Zoran Vasiljevic [EMAIL PROTECTED] wrote:
On 07.10.2006, at 00:39, Stephen Deasey wrote:
But the call may take longer than the caller budgeted for, due to all
the hidden timeouts, which are additive.
True.
So the callers time budget is 5 seconds, and that's what they pass to
What remains:
naming of the module
API (handle vs. handle-free)
ns_exec or ns_slave
i would keep both API, so i would decide in each particular case when
to use which, i do not think they are mutual exclusive
On 07.10.2006, at 17:42, Vlad Seryakov wrote:
to use which, i do not think they are mutual exclusive
This is the impression what I have after all those
emails Although it sounds pretty opportune in
the bad sense of the word, I think that a simple
no-nonsense handle-free API + a handle
On 10/7/06, Zoran Vasiljevic [EMAIL PROTECTED] wrote:
On 07.10.2006, at 17:42, Vlad Seryakov wrote:
to use which, i do not think they are mutual exclusive
This is the impression what I have after all those
emails Although it sounds pretty opportune in
the bad sense of the word, I think
On 07.10.2006, at 19:00, Stephen Deasey wrote:
But the case where you need to serially execute jobs in the slave can
be handled by either passing them all at once, or by using a
'withhandle' command.
What do you think of the withhandle command? Can you get away with
passing everything to the
I am not using it so i have nothing to add to existing API.
As for the name, maybe ns_process or ns_exec ?
Zoran Vasiljevic wrote:
On 04.10.2006, at 10:03, Zoran Vasiljevic wrote:
To summarize. What you object is:
a. handle management (should work without handles)
b. name of the module
On 10/4/06, Zoran Vasiljevic [EMAIL PROTECTED] wrote:
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
On 06.10.2006, at 21:25, Stephen Deasey wrote:
But what I'm wondering is, why you need to do this with proxy slaves?
It seems like they don't have the same state problem that a series of
database statements do.
It's possible to send multiple Tcl commands to a single proxy slave at
the same
I vote for ns_exec and putting it into the core
Zoran Vasiljevic wrote:
On 06.10.2006, at 21:25, Stephen Deasey wrote:
But what I'm wondering is, why you need to do this with proxy slaves?
It seems like they don't have the same state problem that a series of
database statements do.
It's
On 10/6/06, Zoran Vasiljevic [EMAIL PROTECTED] wrote:
On 06.10.2006, at 21:25, Stephen Deasey wrote:
But what I'm wondering is, why you need to do this with proxy slaves?
It seems like they don't have the same state problem that a series of
database statements do.
It's possible to send
On 06.10.2006, at 22:21, Vlad Seryakov wrote:
I vote for ns_exec and putting it into the core
OK. Couple of simple thoughts agout that:
ns_exec ?-pool poolname? script ?arg ...?
is nice and short. It uses the default pool
(as Stephen is advocating).
But... how would we create pools,
On 10/6/06, Zoran Vasiljevic [EMAIL PROTECTED] wrote:
etc ? Or ns_slave?
ns_slave eval arg
ns_slave config thepool option ?value option value ...?
Hm... that's not bad. What do you think?
I think ns_slave would be opportune. The people will of course
immediately ask: where is
On 06.10.2006, at 22:32, Stephen Deasey wrote:
Or, maybe you need a special pool for special threads, and a default
pool for generic threads. If there are only a couple of special
threads then the pool can be small -- you don't need to size the pool
according to the many generic threads just
On 06.10.2006, at 22:53, Zoran Vasiljevic wrote:
OK. So far I can go. I could imagine an API without explicit
handle usage. I can't however imagine scratching them (handles)
altogether.
What I mean by that is that the API should be able to
allow both types of usage.
On 10/4/06, Zoran Vasiljevic [EMAIL PROTECTED] wrote:
On 03.10.2006, at 01:01, Stephen Deasey wrote:
I was also wondering about the ns_proxy send/wait/receive. Why are
wait and receive separate commands?
Because you can wait, get the timeout, do something and then go repeat
waiting. It
On 06.10.2006, at 23:12, Stephen Deasey wrote:
On 10/4/06, Zoran Vasiljevic [EMAIL PROTECTED] wrote:
On 03.10.2006, at 01:01, Stephen Deasey wrote:
I was also wondering about the ns_proxy send/wait/receive. Why are
wait and receive separate commands?
Because you can wait, get the
On 10/6/06, Zoran Vasiljevic [EMAIL PROTECTED] wrote:
On 06.10.2006, at 23:12, Stephen Deasey wrote:
On 10/4/06, Zoran Vasiljevic [EMAIL PROTECTED] wrote:
On 03.10.2006, at 01:01, Stephen Deasey wrote:
I was also wondering about the ns_proxy send/wait/receive. Why are
wait and receive
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
On 03.10.2006, at 01:01, Stephen Deasey wrote:
It's not just the cleanup-up after error. Why does the Tcl programmer
need to get and return resources? It's kind of awkward.
Not necessarily... Think of a handle as a reservation. I take
the handle and I own the resource for some time. In
On Wed, Oct 04, 2006 at 12:05:48PM +0200, Zoran Vasiljevic wrote:
I've been thinking about that...
Basically, what you try to avoid is to replicate common
C-idioms to Tcl because Tcl is not C after all.
Would this include common threading paradigms like
cond wait cond mutex
ns_cond
On 9/18/06, Zoran Vasiljevic [EMAIL PROTECTED] wrote:
On 18.09.2006, at 23:03, Stephen Deasey wrote:
I mean that
Ns_ProxyGet()
might be appropriate for C programmers, but that doesn't mean that
ns_proxy get
is for Tcl programmers. It's not just about level of difficulty
On 9/19/06, Zoran Vasiljevic [EMAIL PROTECTED] wrote:
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
Uh, maybe ns_process?
-- ReC
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Stephen Deasey
Sent: Monday, October 02, 2006 3:06 PM
To: naviserver-devel@lists.sourceforge.net
Subject: Re: [naviserver-devel] nsproxy API
On 9/19/06, Zoran Vasiljevic [EMAIL
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
On 19.09.2006, at 15:32, Vlad Seryakov wrote:
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
On 19.09.2006, at 15:42, Zoran Vasiljevic wrote:
But Stephen has confused me with his last email about problems
in eval command, which I can't see.
Actually we do not need the eval at all!
It is sufficient to:
ns_job queue
ns_job wait
and whoever wants a eval can couple those
two with
On 9/18/06, Zoran Vasiljevic [EMAIL PROTECTED] wrote:
On 18.09.2006, at 20:55, Stephen Deasey wrote:
it's the explicit handle management that's making
things different. Low level C APIs just don't map directly into C.
What C API's ??
Ns_ProxyGet
Ns_ProxyPut
Ns_ProxyEval
are the only
On 18.09.2006, at 23:03, Stephen Deasey wrote:
I mean that
Ns_ProxyGet()
might be appropriate for C programmers, but that doesn't mean that
ns_proxy get
is for Tcl programmers. It's not just about level of difficulty
either. Mapping the low level C APIs directly seems to add a
29 matches
Mail list logo
