On Thu, Aug 09, 2007 at 01:04:06PM -0700, Tom Jackson wrote:
> Subject: Re: [AOLSERVER] aolserver focus

> There are certain things which seem difficult in AOLserver, maybe
> more difficult than they should be, but maybe not.
> One is writing a new C module. I've done some where I use a shared .so module 
> for the interesting library code, and I think I have used a static .la (or 
> whatever it is) file.

Tom, can you elaborate on the difficulty of creating the AOLserver C
module?  Is it just the pointer stuff you mention below?

Back c. 2002, I wrote a (custom) C module for the first time, for
AOLserver 3.x, and then later ported it to AOLserver 4.x.  I was of
course a little lost at first, but by using several of the existing
modules as examples of what I needed to do, I was pleased with how
straightforward it all seemed.

> The difficulty seems to be in using the Tcl C API to 
> make a place to store application data, like handle pointers, etc.

What did you use to do it?

I didn't have too many different types of pointers and such to worry
about, but following the example of some other AOLserver C code, I
used Tcl hash tables (Tcl_FindHashEntry, Tcl_GetHashValue, etc.) to
store process-wide pointers or other values.  It wasn't rocket
science, but that did seem rather low level and fiddly.

For some other strictly per-thread C stuff, I used AOLserver's thread
local storage C APIs (Ns_TlsGet, Ns_TlsAlloc, etc.).  Those were VERY
useful for making API-compatible drop-in replacements for certain
non-thread-safe library functions on Solaris.

Later on, I ended up writing my own little functions to give me
C-level access to these Tcl commands:  array names, nsv_set, nsv_unset,
nsv_get, nsv_exists, nsv_array exists, nsv_array names.

(I haven't looked, but perhaps more recent versions of the Tcl Threads
Extension already include a C API for nsv/tsv.)

I wanted the C-level Tcl array and nsv_* APIs for other stuff I was
doing, but if I'd had them to start with, I probably wouldn't have
bothered using the lower-level Tcl_GetHashValue stuff at all.  For
values which I only needed to use from C (never from Tcl), using Nsv
would have been overkill, but it would also have been more convenient
than the Tcl hash tables.

> Maybe this is just as hard in Apache? Being able to more easily
> reuse existing C libraries would provide a long term benefit.
> Maybe this would be easier with ns_proxy and a single
> threaded/isolated process.

If the external library you're trying to use is not thread-safe and
re-entrant, then sure, it might be easier.  I'm not familiar with how
the ns_proxy process and AOLserver communicate, though.

> Another issue related to C modules is that you can load libnsd into a tcl 
> interp, or just run nstclsh. But you can't load modules, or at least I don't 
> know how to do it. It would probably take a lot of work to get nsd to run as 
> a server inside a tclsh,

Changing AOLserver (and/or tweaking Tcl) so that you can use AOLserver
modules stock from tclsh sounds like something worth trying.

And it would of course be super cool to finish refactoring the
AOLserver codebase so that it becomes "just" a set of libraries for
Tcl, which has been briefly discussed many times before.  Perhaps
making AOLserver modules plug compatible with C-coded Tcl packages
would require that, perhaps not, I don't know.

> Being able to use the database and scheduling APIs in a desktop
> application would be an intesting new area for the AOLserver
> codebase.


Andrew Piskorski <[EMAIL PROTECTED]>

AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> 
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
field of your email blank.

Reply via email to