You could try nsv to manage the list of handles, but you'd need to still
abide by the db handle lifecycle, but that's TCL code.


2013/11/26 Ian Harding <harding....@gmail.com>

> That's enough to get me past this hurdle.  I am not sure this is the right
> path... I think we could make more money by doing less slicing and dicing
> of data in TCL and more in the database.
>
> Thanks!
>
>
> On Mon, Nov 25, 2013 at 1:16 PM, Jeff Rogers <dv...@diphi.com> wrote:
>
>> Ian Harding wrote:
>>
>>> I have a mountain of code in TCL, and I am thinking of rewriting some of
>>> it in C.
>>>
>>> In a C module I have a function that is registered to an URL. Like I
>>> said, I have a bunch of TCL code that I would like to be able to use
>>> until (if ever) it gets rewritten.
>>>
>>> I see that I can execute TCL code and get a string back via
>>> Ns_TclEval(). It seems to work, but my first attempt, foolishly, was to
>>> use a utility TCL proc that returns a db handle. I can execute it, and I
>>> get the string that represents the name of the handle, but that's not
>>> exactly the same as a C Ns_DbHandle.
>>>
>>> Is there any way to share stuff like db handles back and forth like that?
>>>
>>
>> The function to get a Ns_DbHandle from a handle name is
>> NS_EXTERN int Ns_TclDbGetHandle(Tcl_Interp *interp, char *handleId,
>>                              Ns_DbHandle **handle)
>>
>> You still have to honor the db handle lifecycle (i.e., release it at the
>> end of a request) and sharing restrictions (don't share across threads)
>> when you're in C code.
>>
>>
>>  I saw some functions for sharing an Ns_Set, but that's about it.
>>>
>>> I would appreciate any pointers for this kind of thing... I am just
>>> getting started.
>>>
>>
>> The header files in "include" are the definition of the public API.  A
>> lot of the functions aren't well documented separately, but most are
>> documented in their source files.  Using 'ctags' is helpful.
>>
>> Why are you rewriting?  If it's intended for performance, make sure you
>> are testing your performance and addressing the hotspots and not just
>> things that look like they might be slow.
>>
>> There is an aolserver channel on freenode, it's quiet but there's
>> typically a few people there.  Feel free to stop by.
>>
>> Pretty basic pointers here, but they're all I have at the moment :)
>>
>> -J
>>
>
>
>
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing
> conversations that shape the rapidly evolving mobile landscape. Sign up
> now.
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> _______________________________________________
> aolserver-talk mailing list
> aolserver-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/aolserver-talk
>
>


-- 
"A scrum a day keeps the pigs at bay"
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
aolserver-talk mailing list
aolserver-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/aolserver-talk

Reply via email to