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. Yep. -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/ -- 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.
