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
> either. Mapping the low level C APIs directly seems to add a lot of
> difficulty, because you have to take account of the Tcl environment
> and all the crazy things that you just don't allow in the C API.
Aha. Well, in that particular case, the [ns_proxy get] is not bad at
all!
You get the handle of "something" that you use to do all kinds of
things.
Later on, when you're done with it, you [ns_proxy put] itback, allowing
others to use the same "something"
How would you make this in a "Tcl way"?
After all, you [open] the channel, then you [puts] to it and then
[close] it. What is not OK here?
I think I know where are you heading and I can understand the idea
but this particular example may not be optimal.
I believe you are thinking about something like this:
ns_mutex lock $lock
do bla bla bla
ns_mutex unlock $lock
The "optimal" way to do that would really be:
ns_mutex lock $lock {
do bla bla bla
}
as it will save you the trouble if "do bla bla" throws error.
In the latter case you must ugly things like
ns_mutex lock $lock
if {[catch {do bla bla} err]} {
ns_mutex unlock $lock
error $err
}
ns_mutex unlock $lock
which is just plain rubbish (because of which we had to invent
our own do/catch/finally command)...
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.
For example:
ns_serialize {
# whatever
}
is better than the mutex example above because you also don't have to
mess around with the mutex handle and nsv arrays. The Tcl code in the
code block serves as a key into a hash table of locks, created on
demand. We can let the code block shimmer to an object which contains
both a byte code script and a mutex pointer. It will run as fast as
possible the second time round.
More complicated syntax for a more complicated operation:
ns_serialize -lock mylock {
# whatever
}
Now you could run two different code blocks using the same lock. But
you still don't have to allocate mutex objects, pass around their
names in nsv arrays, and so on.
I don't think the above is dumbed-down. It's a much nicer way to work
with Tcl, and you just wouldn't do this kind of thing from C.
Anyway, back to nsproxy. Thinking about it further, it looks like the
explicit handles are actually there to allow a particular kind of Tcl
programming, not necessarily because explicit handle management is
needed. i.e.:
set x [create ...
$x method ...
Which is perhaps not a bad way to manage the handles if you absolutely
need them. But if you can instead do:
ns_proxy eval {
# whatever
}
which in the case of a default pool and a single evaluation, you can,
it's got to be better than the explicit handle management, right?
This is basically identical to the db module. People hate manging db
handles, which is why the ACS style db_* API is so popular.
I was also wondering about the ns_proxy send/wait/receive. Why are
wait and receive separate commands?
Also, does there need to be so many timeouts? The waittimeout is 100
msec. That means if all else goes well, but the wait time takes 101
msec, the evaluation will not be successful. But looking at the other
defaults, the script evaluator was prepared to wait (gettimeout 5000 +
evaltimeout infinite + sendtimeout 1000 + recvtimeout 1000), or
between six seconds and forever... Wouldn't a single timeout do?
It would also be great if the timeout error code began with the
NS_TIMEOUT symbol, which if not caught will automatically trigger a
Server Busy error page.
