On 05.10.2006, at 00:27, Mike wrote:
<lots of interesting text cut>
Zoran, Stephen,
To me, what this discussion says most of all is that the current
approaches to handling synchronization primitives in naviserver are
way too complicated for human consumption.
Well, we have most (all?) basic blocks exported to Tcl level.
This allows you (a Tcl programmer) to build just about anything
that C-programmer can do in that area. Unfortunately, using the
same idioms that C-programmer is used to, which may seem odd to you.
Perhaps the "correct" approach is to actually examine real-world use
of these primitives and find a "better" approach to the problem that
can leverage the power of Tcl (something closer to the stuff Stephen
was pointing out earlier) but not necessarily losing the power of free
handles that Zoran believes are useful.
It is true that we'd yet to find something like that. It isn't easy
though. At the moment we are discussing whether handles or tags are
better, obviously neglecting the fact that the whole concept is actually
"foreign" to the Tcl programmer.
I don't have the vaguest idea
what that mechanism may be - but all you guys are doing right now is
throwing around hypothetical use cases. I have yet to see a solid
example in this thread that would lead me to believe one would ever
want to use a mutex or condition variable anywhere in naviserver at
all.
Ah... in some cases you have no choice! Every time you have some code
that may execute in 2 connection (or other) threads at the same time
and that accesses the same resource (a file or piece of memory) you
need to lock and for that you need all those sync primitives.
In some cases there are "abstractions" or "helpers" like ns_job or
nsv where most of that ugly locking issues is hidden from you. But
you can't abstract everything.
From what I see, we are already very good: there is nsv which allows
you to store/access scalar values across threads w/o explicit locking.
Then we have caches which are thread-wide, also we have ns_job so you
can start parallel jobs and wait for them, all w/o any special locking
or synchronization of your own. The only piece that I miss is the
ability
to park a thread as a "script evaluator" in the way that Tcl threading
extension does. So with all those tools, you can mostly avoid any own
synchronization. But you can't really avoid it for some special cases.
