On 18.04.2006, at 22:48, Stephen Deasey wrote:
An API that allows easy sharing between C and Tcl code is an
interesting idea, e.g. a filter written in C storing data for a page
written in Tcl. But that's not what's been implemented.
Too bad. I thought it is something in this direction.
As it stands, it's possible for C code to call down to Tcl and grab a
global variable, it's impossible to get at the tls data as the tls key
is a private variable in the nsd/tclinit.c file.
One bug with the current implementation is that virtual servers will
stomp on each others data.
Even worse. Hm... in that case I'd put this out of the server
and into the module.
Normally I do not have anything against extending core
server but the more things we put into, the more things
need to be maintained, tested, understood, etc... So
on one side I'd love to see more features and on another
I have headaches when thinking about what we already have
inside and what we alone do not grasp. Temptation is strong
to add something ad-hoc to solve an immediate problem but we
should really make our life little bit more difficult on the
short term by writing an RFE first and then discuss, eventually
bless it and then integrate it in the core. I know this sounds
somehow buerocratic but this little burden will pay off for sure
on the long term.
For the current tls issue: ideally I'd see something like
simple way of handling stuff from Tcl and from C code which
I thought ns_tls is (would be). A Ns_Set seems OK as it has
both C and Tcl api. And, sets can be shared (thread-wide) and
thread private, so instead of pulling yet-another data-structure
inside, why not see if Ns_Set is enough for what Vlad is needing?
Cheers
Zoran
On 4/18/06, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
Not you exactly but both of you and Stephen:-)))
Global Tcl vars is more cleaner Tcl-only solution but i agree
interoperability between C and Tcl using ns-tls would be a good
feature.
Internally ns_tls keeps Ns_set, so getting this from C would be just
gettting pointer to Ns_Set structure. It just requires more C-level
calls something like Ns_GetTclTls()/Ns_SetTclTcls()
Zoran Vasiljevic wrote:
On 18.04.2006, at 15:52, Vlad Seryakov wrote:
You convinced me that at this moment ns_tls is not appropriate,
i will
remove it
Oh?! How did I do that? Apart from giving a trivial
alternative, I think that this interface is ok per-se.
It allows "unified" access from Tcl and C code.
That is, one should be able to do the "same" from C
and Tcl. Isn't it so?
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&kid0944&bid$1720&dat1642
_______________________________________________
naviserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
