Re: [naviserver-devel] hosting java-script server-side?

[Stephen D. <sd...@gm...>]

On 9/18/06, Vlad Seryakov <vl...@cr...> wrote:
> >
> > People are writing a lot of sucky Tcl for AOLserver.  Here's an
> > example from a couple of days ago:
> >
> >
> > proc startworker {name} {
> >        nsv_set $name mutex [ns_mutex create]
> >         nsv_set $name cond  [ns_cond create]
> >        nsv_set $name queue {}
> >        nsv_set $name tid [ns_thread begindetached [list workermain $name]]
> > }
> >
> > Jumping through hoops with low level mutexes and and variables etc.,
> > you see it all the time.  Why can't we have code that looks like this?
> >
> >     ns_serialize {
> >         # Only one copy of this code runs at a time
> >     }
> >
> >
> > Which brings us back to nsproxy and handle management... :-)
>
>
> You just showed that it is not Tcl sucks but a programmer that writes
> bad code in Tcl without using it properly or not in full. That example
> of your shows that programmer that wrote it has more experience in C and
>   uses Tcl in pure procedure way, which is not that bad, the code works.
>


The programmer above used the API correctly, it's the API that sucks.

To lock a mutex you need to first create it and save the handle. You
need the handle in all the threads which will use the mutex, so you
put it in a global nsv array where all threads can retrieve it.

So at run time, you lock the nsv array, get the name, unlock the nsv
array, lock your mutex, do your stuff, unlock the mutex. There's
double the necessary locking and it's a real pain in the ass.

(It's different in naviserver. you can pass in a string name for the
mutex, and if it doesn't exits, it's automatically created. this
mostly works...)