Re: [naviserver-devel] ns_cond wait (Was: hosting java-script server-side?)

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

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.