On 10/4/06, Andrew Piskorski <[EMAIL PROTECTED]> wrote:
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 has exactly the same semantics and usage style as the C
pthread_cond_*() functions which underly it, and thus is precisely as
confusing and low-level as they are. This is annoying, especially
when using ns_cond for the first time.
However, it also has the important ADVANTAGE that the ns_cond
implementation is simple, and that you know that ns_cond* and
pthread_cond_* are in fact intended to work EXACTLY the same way.
ns_cond has been extremely useful to me on the rare occasions when I
needed it, but the average Naviserver user probably never uses it even
once. And AOLserver (and thus Naviserver) has had ns_conf for many,
many years. I bet the original ns_cond implementor couldn't think of
a much better design, so he did the obvious simple thing: just wrap
the ugly C APIs as is.
Designing better, high level, Tcl-ish APIs is non-trivial. And if
you're going to design some better high level API for waking up a
thread, why even pollute your thinking with low-level "condition
variable" stuff at all? Zoran, I think you've already got some nice
message passing style stuff in your Threads extension, maybe it would
make more sense to add some friendlier "Heh thread X, wake up, you've
got work to do now!" style API there?
And if so, I'd say leave ns_cond alone, it's just a low-level wrapper
around pthread_cond_*, and that's fine.
ns_cond is a *literal* implementation of the underlying C API. An
ns_cond which takes a condition name rather than a handle is a
*faithful* implementation of the underlying C API. Which is entirely
different than the hypothetical ns_serialize command which has no C
equivalent.
The reason that a name based ns_cond makes sense as a low level
building block, deviating from the C tradition of passing a handle
around, is that Tcl is a different environment.
Each thread has it's own Tcl interp, yet each thread must use the same
condition variable. In C this is not a problem. Memory is shared so
you can use a global variable to hold the condition var, and this is
really easy. In Tcl, you have to some how communicate the handle to
each interp, and this is painful.
Which leads to the crazy situation where it's is easier to use
condition variables from C than it is in Tcl..!
So yes, we need to be careful when creating APIs that when we strive
for simplicity we do not make it difficult or impossible to do things
a little out of the ordinary. But we also need to remember that Tcl
and C are different so that a low-level command does not necessarily
have to be a literal translation of the C API.
