Menu
▾
▴
naviserver-devel
|
From: Zoran V. <zv...@ar...> - 2006-04-14 16:27:44
|
Hi Vlad, Just out of the curiosity... what you need that beast for? Why just not address some global array or such? Tcl interp is per-thread anyways so you get this for free. Obviously there is some hidden usage otherwise you would not go to that extent. Can you share it? Cheers Zoran |
|
From: Vlad S. <vl...@cr...> - 2006-04-14 16:37:06
|
Sure, currently i am using global Tcl vars to store thread data but over the time code that supports this became kind of ugly, too many things i need to store during the connection lifetime, i tried multiple variables, then global array but for example in C, i use Ns_Tls and this works very good, so i kind of wanted to have the same functionality in Tcl as well. For one simple var global Tcl is fine but my application is very big right now and i had to create the Tcl wrapper around accessing global Tcl vars/arrays from different procs and namespaces. Using Tls would simplify this and make it very transparent when i want to access thread specific global data. This is very subjective but it will make my life much easier and application more cleaner by using Tls in Tcl, so if nobody will object i would keep ns_tls command if possible. Zoran Vasiljevic wrote: > Hi Vlad, > > Just out of the curiosity... what you need that > beast for? > Why just not address some global array or such? > Tcl interp is per-thread anyways so you get > this for free. > Obviously there is some hidden usage otherwise > you would not go to that extent. Can you share > it? > > Cheers > Zoran > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Zoran V. <zv...@ar...> - 2006-04-14 16:42:12
|
On 14.04.2006, at 18:36, Vlad Seryakov wrote: > This is very subjective but it will make my life much easier and > application more cleaner by using Tls in Tcl, so if nobody will > object i would keep ns_tls command if possible. Absolutely! I have no problem with that, whatsoever. It is just that I was curious *when* you start needing such things, as we never did. We need(ed) thread-wide things (so nsv_ is ok) but not thread-specific. Good to know... Cheers Zoran |
|
From: Vlad S. <vl...@cr...> - 2006-04-14 16:47:59
|
Yes, i always use Tcl vars but when i have too many different callbacks and filters, using simple mechanism to access named value that is global inside the thread make it easier than performing multiple global statements over the code. If i want to add another var, i need to create Tcl wrapper so i do not need to go over the code and see where i may use it, so in this case ns_tls will make it easier. But in general, global Tcl var is way to go. Zoran Vasiljevic wrote: > > On 14.04.2006, at 18:36, Vlad Seryakov wrote: > >> This is very subjective but it will make my life much easier and >> application more cleaner by using Tls in Tcl, so if nobody will object >> i would keep ns_tls command if possible. > > Absolutely! I have no problem with that, whatsoever. > It is just that I was curious *when* you start needing > such things, as we never did. We need(ed) thread-wide > things (so nsv_ is ok) but not thread-specific. > Good to know... > > Cheers > Zoran > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Stephen D. <sd...@gm...> - 2006-04-15 22:34:07
|
On 4/14/06, Vlad Seryakov <vl...@cr...> wrote: > Yes, i always use Tcl vars but when i have too many different callbacks > and filters, using simple mechanism to access named value that is global > inside the thread make it easier than performing multiple global > statements over the code. If i want to add another var, i need to create > Tcl wrapper so i do not need to go over the code and see where i may use > it, so in this case ns_tls will make it easier. But in general, global > Tcl var is way to go. If the main motivation is convenience, can't you just write some simple Tcl wrapper around global arrays? A disadvantage of the way you have it now is that everything is stringified before it's stored in the set, and re-objectified on the way out. This is a pretty specialised function. I don't think the core is the right place for it. |
|
From: Vlad S. <vl...@cr...> - 2006-04-16 00:56:15
|
Yes, it is more convenience but even nsv_ shared variables work the same way, keep stringified values and objectifies on the return. We decided to get rid of thread specific caches and keep global ones only, and at that time i was for it but now i think simple thread local cache should be in the core to offer more flexibility to the developer. But i am not insisting. Stephen Deasey wrote: > On 4/14/06, Vlad Seryakov <vl...@cr...> wrote: >> Yes, i always use Tcl vars but when i have too many different callbacks >> and filters, using simple mechanism to access named value that is global >> inside the thread make it easier than performing multiple global >> statements over the code. If i want to add another var, i need to create >> Tcl wrapper so i do not need to go over the code and see where i may use >> it, so in this case ns_tls will make it easier. But in general, global >> Tcl var is way to go. > > > If the main motivation is convenience, can't you just write some > simple Tcl wrapper around global arrays? A disadvantage of the way > you have it now is that everything is stringified before it's stored > in the set, and re-objectified on the way out. > > This is a pretty specialised function. I don't think the core is the > right place for it. > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642 > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Stephen D. <sd...@gm...> - 2006-04-16 15:04:30
|
On 4/16/06, Vlad Seryakov <vl...@cr...> wrote: > Yes, it is more convenience but even nsv_ shared variables work the same > way, keep stringified values and objectifies on the return. But for nsv shared variables you *have* to stringify because Tcl objs can not pass between threads. Here your explicitly looking for thread local, so stringifying would seem to be an unnecessary slowdown. > We decided to get rid of thread specific caches and keep global ones > only, and at that time i was for it but now i think simple thread local > cache should be in the core to offer more flexibility to the developer. This isn't a cache, there's no eviction policy. I don't see how ns_tlsthis isn't exactly equivalent to: set ::tcl_MyMache Whatever which has the big advantage of keeping Tcl objects in object form. |
|
From: Vlad S. <vl...@cr...> - 2006-04-16 17:28:26
|
> > But for nsv shared variables you *have* to stringify because Tcl objs > can not pass between threads. Here your explicitly looking for thread > local, so stringifying would seem to be an unnecessary slowdown. Mostly we store strings in the cache so it is not a real problem > This isn't a cache, there's no eviction policy. > But if i do not need eviction policy, if i want to keep them forever? > I don't see how ns_tlsthis isn't exactly equivalent to: > > set ::tcl_MyMache Whatever > > which has the big advantage of keeping Tcl objects in object form. True, and i am still using it this way, i even use global arrays to be able to get all values easily. But i have a lot of filters and callback procedures that are called from different places even from C modules. Calling Tcl wrapper all the time is a big slow down especially if i need to process several hundreds of rows, tls will be a big improvement in this case. But i agree that functionality-wise it is the same -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X