Re: [AOLSERVER] interpreter lifecycle
Am 27.05.2005 um 00:47 schrieb Jeff Hobbs: This I will disagree with. If you can handle it all in C, I think you will save time. A lot will be in the copying itself, but saving any and all parsing is a bonus. Hmmm...since the scripts will have to jump interp/thread, they need to be re-parsed from source to bytecodes again, don't they? If this is true, then what is actually saved? I do also believe that C-coded clone-routine will be faster than doing it all from Tcl alone but I'm afraid that it still will be too slow when it comes to duplicating a potentially large (i.e. heaviliy loaded) interp. Again, I still believe that some kind of lazy-loading plus usage of slave interp and clever aliasing could be the way to go if people need the 100% cleanness. But, as we all know, speed i.e. performance is best tested (and judged) by trials and experimentation. Zoran -- 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.
Re: [AOLSERVER] interpreter lifecycle
Howdy,
I've been following this thread the last few days -- great discussion. Let me add a few points and suggest how we can move forward.
First, I'm responsible for the current approach of initializing Tcl interps in AOLserver and I agree with Zoran -- it's clumsy. Aside from failure on my part to keep things simple, the current state reflects AOLserver's age (10 years now, should we have a celebration?) which pre-dates useful Tcl features, in particular packages and namespaces. In lieu of packages, AOLserver used it's "module" initialization framework to handle Tcl initialization which is non-standard, not namespace-aware, and complicated by "shared" and "virtual server" confusion.
I also agree with Zoran that "cloning" would be hard to get right. I understand how low-level C-copying of most things could be fast. In fact, pre-opensource versions of AOLserver went a step beyond cloning and actually linked interps together, sharing command and global variable tables so new interps would flash into existance with (most) state ready to go. Everything was great except I had to hack too much of the Tcl core, too many locks where involved, and there was confusion between global and "ns_share" variables. More importantly, cloning wouldn't solve the full problem which includes not only initialization but regular garbage collection and re-init between transactions/connections.
I've done two things in the current 4.5 code to try and simply things. First, I added a bunch of comments in nsd/tclinit.c so one can follow the arcane flow of virtual-server startup init and then interp lifetime. More importantly I added a new API, Ns_TclRegisterTrace, (unfortunately undocumented) which allows one to add C callbacks at the key Tcl interp state transition points: create, allocate, deallocate, and attach and detach from a connnection. You can use the "ns_ictl" command to register Tcl-script level traces as well. The legacy code (e.g., Ns_TclInitInterps) has been modified to use the new API. While technically possible, it turns out without the new interface it was difficult to really control these points. Another problem with the pre-4.5 model is it set the wrong expectation, that either the default would do the right thing with all the state extraction and copying or that the code could not be easily extended (I don't get the sense many folks modify the "ns_init" and "ns_cleanup" procs).
So, here's a suggestion on how to move forward:
1. Avoid the cloning idea as we've been there before and it never really worked perfectly. And, when interps are well managed and are retained transaction to transaction, the time spent creating the interp tends to zero when amortized over the long lifetime of the interp so the overhead gain, if any, isn't so critical.
2. Modify existing code to be actual packages. I've started this already with AOLserver core itself, e.g., the following should work:
# /usr/local/aolserver/bin/tclsh8.5
% lappend auto_path /usr/local/aolserver/lib
% pkg_mkIndex /usr/local/aolserver/lib
% package require Nsd
4.5
% info comm ns*
... a bunch, but not all, AOLserver commands ...
3. Use the package interface along with ns_ictl to manage state clearly, e.g., replace the confusing code in bin/init.tcl with the following and expect folks to own this config for their own install as they do with nsd.tcl:
ns_ictl trace create {
package require Nsd
package require Foo
package require Bar
}
ns_ictl trace dealloc {
... default cleanup for Nsd, clear ns_sets, etc...
... cleanup, if any, for Foo, Bar, etc.
}
4. Give up on general dynamic reconfig via ns_eval, instead use ns_ictl again for specific interfaces:
ns_ictl trace alloc {
... check for some update, e.g., a control file change or something to act on...
}
5. Finally, the last thing we should consider is giving up on virtual servers. It turns out that there is still quite a bit of code complexity to support virtual servers and more importantly it confuses the "process" init with "server" init, limiting our ability to turn AOLserver completely into a Tcl loadable module which would really simplifiy interp management and align with normal Tcl practice. This is something to consider later.
-Jim
2">
Re: [AOLSERVER] interpreter lifecycle
On Saturday 28 May 2005 08:14, Jim Davidson wrote: 5. Finally, the last thing we should consider is giving up on virtual servers. It turns out that there is still quite a bit of code complexity to support virtual servers and more importantly it confuses the process init with server init, limiting our ability to turn AOLserver completely into a Tcl loadable module which would really simplifiy interp management and align with normal Tcl practice. This is something to consider later. YES! I've spent some time getting nice cleanish config files setup to use virtual servers, and I still think it is a big mistake to use it. Every argument I've seen in support of virtual servers is better answered by either a home brew solution, using a single server for multiple domains, or by just using another web server (like Apache). The main reason being, you just can't isolate servers, they have the same user/group permissions, exposing every other virtual server to potential attack or programming mistakes. Another reason is that configuration information is static. Any changes require a restart of every virtual server. Startup time is the combined startup for all virtual servers, plus the main config. Whatever the external benefit of virtual servers is, the C level coding is complicated too much, which impacts maintenance and development. tom jackson -- 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.
Re: [AOLSERVER] interpreter lifecycle
In a message dated 5/28/05 11:37:23 AM, [EMAIL PROTECTED] writes:
3. Use the package interface along with ns_ictl to manage state clearly, e.g., replace the confusing code in bin/init.tcl with the following and expect folks to own this config for their own install as they do with nsd.tcl:
ns_ictl trace create {
package require Nsd
package require Foo
package require Bar
}
ns_ictl trace dealloc {
... default cleanup for Nsd, clear ns_sets, etc...
... cleanup, if any, for Foo, Bar, etc.
}
Actually, I meant to point out that unlike the current single ns_init and ns_cleanup procs which the example above seems to follow, there can be mulitple ns_ictl calls -- they're called in FIFO order. So a better example would be:
ns_itcl trace create {
package require x
package require y
}
in package x:
ns_ictl trace dealloc {... cleanup for x ...}
in package y:
ns_ictl trace alloc { ... reinit for y ...}
etc., i.e., the packages can own whatever's need to re-init, cleanup, etc. This should make it easier to keep things clean and separated on a package by package basis.
Actually, now that I'm writing this it occurs to me the FIFO order always is wrong -- instead it should be FIFO for init-type things (create, alloc, getconn) and LIFO for cleanup type things (dealloc, freeconn, delete). I'll fix that.
-Jim
2">
Re: [AOLSERVER] interpreter lifecycle
Am 26.05.2005 um 00:46 schrieb Jeff Hobbs: Complex, yes, but still possible. Well... see: * Limitation: For C-based 'commands' with a non-NULL client data * we do not know how to handle this. For the moment we simply * copy the pointer. In the future commands may need a duplication * method which is able to handle their client data. I remember now, this was *one* of the points where I threw the towel. We'd need some extension to the current command handling to allow the clientData dups... Apart from that, I see that the whole clone-process is doing what it is expected to, but somehow I have mixed feeling about the general usefulness of that. For example, when you load some extension in one thread/interp, this can have many side-effects which are not visible in that interp only. So, without actually loading the extension again in the other thread, you might miss some pieces. The extension can maintain per-thread private structures which are not part of the interp and thus not cloned. So, in order to cover this, one must also re-load all extensions. I cannot anticipate what side-effects this could create in conjuction with C-level namespace copies done by the Tcl_CloneInterp... This interp-cloning looks very appealing on the first glance but when you dig deeper, things start to complicate. Also, although all in Tcl_CloneInterp is done in C, I'm afraid that it could still take considerable time to copy 1000 or so commands plus variables plus reload extensions. This might bless you with a 10's of milliseconds speed penalty which I do not believe people are willing to accept. By introducing *whatever* kind of garbage-collection or interp-cloning, there will be (perhaps significant) speed issues introduced and everybody should be perfectly aware of that. What also comes to mind is: create a slave interp, fill it with aliases to master interp commands, run the request in the slave and then trash the slave entirely. One would eventually need to pay attention programatically *never* to change important state data in the master but this would be out of the scope of the implementation. I never actually tought deeper about that but it is worth considering it as an option. Of curse, one would then need something similar to Tcl_CloneInterp, but this is far more simpler to do and would have no MT-related side-effects. Zoran -- 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.
Re: [AOLSERVER] interpreter lifecycle
On Thu, May 26, 2005 at 10:59:16AM +0200, Zoran Vasiljevic wrote: Also, although all in Tcl_CloneInterp is done in C, I'm afraid that it could still take considerable time to copy 1000 or so commands But Jeff H. said it has already been done single-threaded on that Tcl 8.3.x branch for Cisco, and that it was very fast! So, are you saying that multi-threaded Tcl needs something done DIFFERENTLY, and that you suspect/fear that those differences would introduce a large slowdown? Or what? -- 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.
Re: [AOLSERVER] interpreter lifecycle
Am 26.05.2005 um 11:47 schrieb Andrew Piskorski: On Thu, May 26, 2005 at 10:59:16AM +0200, Zoran Vasiljevic wrote: Also, although all in Tcl_CloneInterp is done in C, I'm afraid that it could still take considerable time to copy 1000 or so commands But Jeff H. said it has already been done single-threaded on that Tcl 8.3.x branch for Cisco, and that it was very fast! So, are you saying that multi-threaded Tcl needs something done DIFFERENTLY, and that you suspect/fear that those differences would introduce a large slowdown? Or what? First, I doubt that the process will be fast enough when applied to tons of loaded procedures, namespaces, variables and all of those things you would need to copy from an AS initialized interpreter. Remember, this has to be done on each new page-request! This will chew-up pretty much of your CPU, regardless if you do it in C or not. Second, I doubt that this approach (interp-cloning) will be feasible generally since not all things *are* actually in the interp alone. Some packages need to be loaded per-thread specifically since they (must) maintain some thread-specific state. Hence, it is not sufficient just to clone the interp alone. You must also clone that (package specific and non-interp) data. How would you do that in a generic way? AFAIK, there is no other way to achieve this but re-loading the package on per-thread basis. But then, why would one need cloning of the interp? The more I think of this, the less I'm convinced that anything will work satisfactorily. One small light at the end of the tunnel would be the slave-interp approach as I described in my previous mail. One still have to checkout what would it mean (speedwise) to wholesale alias the entire AS interp in a slave. Also, one would need to revise the application logic to cope with globally accessible data (data from the master interp). All in all, this would require changes in both server (not that much) and application logic (pretty much) but could be a way one might go if the cleaness of the interp between requests is of the utmost importance. Zoran -- 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.
Re: [AOLSERVER] interpreter lifecycle
Am 26.05.2005 um 11:47 schrieb Andrew Piskorski: On Thu, May 26, 2005 at 10:59:16AM +0200, Zoran Vasiljevic wrote: Also, although all in Tcl_CloneInterp is done in C, I'm afraid that it could still take considerable time to copy 1000 or so commands But Jeff H. said it has already been done single-threaded on that Tcl 8.3.x branch for Cisco, and that it was very fast! So, are you saying that multi-threaded Tcl needs something done DIFFERENTLY, and that you suspect/fear that those differences would introduce a large slowdown? Or what? Just as a continuation to my previous answer... I think if you *combine* the slave-interp (as described) and use my ttrace package to lazy-load (in which case it would be rather lazy-alias) *only* those parts of the command-set of the master interp which are needed for the currently executing page, the thing *could* work with acceptable speed. So instead of aliasing 1000's of commands from the master at once and every time, ttrace would lazy-alias only parts of it. After the request is done, the slave is trashed entirely. It requires some testing/coding to see just how about fast this would work. But, it also requires app-code changes (no more direct variable access; all must be done with procedure calls aliased from the master) and I do not know if the people would be willing to make such a step just to get the pristine interp. All of us learned to live with what's available and with all it pros and cons. Zoran -- 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.
Re: [AOLSERVER] interpreter lifecycle
Zoran Vasiljevic said: First, I doubt that the process will be fast enough when applied to tons of loaded procedures, namespaces, variables and all of those things My thought exactly. Nice for new interpreter creating, but not for per-request use. I don't see how the current AOLserver way of dealing with this can be improved, I find it works well and is very intuitive. Just my $0.02... -- 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.
Re: [AOLSERVER] interpreter lifecycle
On Thu, May 26, 2005 at 12:27:50PM +0200, Zoran Vasiljevic wrote: First, I doubt that the process will be fast enough when applied to tons of loaded procedures, namespaces, variables and all of those things you would need to copy from an AS initialized interpreter. Remember, this has to be done on each new page-request! This will chew-up pretty much of your CPU, regardless if you do it in C or not. Well, Zoran, you're looking at the code and I'm not, but none of that seems to jive with what Jeff H. has said before. So if you are serious about maybe working on this stuff (yeah!), I recommend talking to him and getting lots more details... -- 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.
Re: [AOLSERVER] interpreter lifecycle
Am 26.05.2005 um 12:53 schrieb Andrew Piskorski: Well, Zoran, you're looking at the code and I'm not, but none of that seems to jive with what Jeff H. has said before. So if you are serious about maybe working on this stuff (yeah!), I recommend talking to him and getting lots more details... The Tcl_CloneInterp() is just as simple as: walk over the namespaces get all procs/commands copy them to target interp (copy clientData ptr of commands) get all vars copy them to target (sharing instead of deep-copying Tcl_Objs) and some other small plumbing here/there (errorInfo, errorCode, math functions). It is really no rocket science. The clientData ptr copy is a problem. This is not solvable w/o redefining the Tcl command struct to hold the clientDataDup call. The sharing instead of deep-copying Tcl_Objs is MT-issue which can be solved generally by getting the string rep of the Tcl_Obj and copying the string rep only but maintaining the object type. As you see, this is nothing very fancy. Yet, I doubt it will be acceptable speedwise, being it in C or not. Again, if people are willing to change the *model* of the app (never use global/namespace vars w/o proc-wrappers, never have those wrappers *modify* master-interp data, etc) then all sorts of things can be arranged. I'm not that convinced that this all is worth doing *now*, although I must say if I'm about to make this from *scratch*, then I'd do it this way. Zoran -- 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.
Re: [AOLSERVER] interpreter lifecycle
On Thu, May 26, 2005 at 01:36:12PM +0200, Zoran Vasiljevic wrote: The sharing instead of deep-copying Tcl_Objs is MT-issue which can be solved generally by getting the string rep of the Tcl_Obj and copying the string rep only but maintaining the object type. Ah, so that's the part that is different between the single and multi threaded cases, and presumably why the single-threaded case was fast enough for a clone a new interp to service each request on a Cisco router? Here's a naive, clueless-because-I-have-not-read-the-source question: Is some sort of copy-on-write feasible, for the multi-threaded case? Or would it even help, if it was possible? -- 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.
Re: [AOLSERVER] interpreter lifecycle
Hiya (Nice to see all this discussion.) Dossy Shiobara wrote: While it would be easy to add the necessary code to clean up namespace variables, I think it isn't being done because doing it could get expensive because, in order to implement it, we'd have to iterate over every single namespace (which could be a large number) then retrieve the list of variables per namespace and unset them. Certainly makes sense with the current architecture. Avoid namespaces. :-) Well, namespaces are very handy. I've used them in the past for both things that are meant to be server level, and also in libraries that may get used at the request level in several scripts. The latter is particularly useful as you can happily use functions without worrying about poluting the caller's scope or doing messy things like passing variable names and upvar'ing. I'm certainly not in a position to rewrite all the code I've got that already uses namespaces. However, I'm pretty sure that a fair amount of it is re-use safe in that the API ensures the namespace variables are cleared/initialised appropriately on each invocation. Some code review will be required to confirm this, but I can probably live with that. Jim's singlescript or whatever it was called will do what you want: the entire ADP gets turned into a single script, and an error anywhere in it will abort the entire script, naturally. Yes, I mentioned that before as fulfilling the requirement (though doing a bit more which whilst not necessary for me, shouldn't hurt). Hence my question regarding a 4.1 release. PS: I plan to update the wiki in the next few days - I'll post here afterwards so people can correct my mistakes. :) Cheers -- Stuart Children -- 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.
Re: [AOLSERVER] interpreter lifecycle
Am 26.05.2005 um 13:58 schrieb Andrew Piskorski: Here's a naive, clueless-because-I-have-not-read-the-source question: Is some sort of copy-on-write feasible, for the multi-threaded case? Or would it even help, if it was possible? This piece alone is not the only obstacle. The more important obstacle is: huge number of *things* affected by the process (each and every procedure must be copied, each and every C-level command, each and every global/namespaced variable, etc. etc.). Doing this on *each* request will just dwarf your CPU on any reasonable production site. Another important obstacle: copying commands is not enough since packages do have the freedom to do whatever they like, when loaded. If you were to *properly* address this, then you need to reload the package every time you clone the interp. In which case you needn't copy it's commands... Also, copying commands w/o copying their clientData properly is not going to work. This is how 3.x AS worked and it was plain wrong. Hence the 4.x has completely different (and more correct) approach. Zoran -- 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.
Re: [AOLSERVER] interpreter lifecycle
Bas Scheffers wrote: Zoran Vasiljevic said: First, I doubt that the process will be fast enough when applied to tons of loaded procedures, namespaces, variables and all of those things My thought exactly. Nice for new interpreter creating, but not for per-request use. If the interpreter cloning were made viable, then you could easily make this configurable in the same manner that interpreter lifetime is now (though my researching has unearthed comments that connsperthread != 0 may not currently be safe?). Then people would be free to choose between having a known starting state interpreter but a potential performance hit, vs dealing with namespaces persisting. I don't see how the current AOLserver way of dealing with this can be improved, I find it works well and is very intuitive. It certainly seems to work if your code is written with it in mind, and now I know what's going on I can deal with it. So there's just a documentation issue which is certainly easy to fix! And I intend to. -- Stuart Children -- 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.
Re: [AOLSERVER] interpreter lifecycle
Zoran Vasiljevic wrote: Am 26.05.2005 um 13:58 schrieb Andrew Piskorski: Here's a naive, clueless-because-I-have-not-read-the-source question: Is some sort of copy-on-write feasible, for the multi-threaded case? Or would it even help, if it was possible? I've taken a peek at the source, but as mentioned before, I'd have to brush up on my TCL internals knowledge before I can do anything with it - though it would be quite interesting so I may persue this as learning project if nothing else. If anyone else is interested, this seems to be where things got to: http://cvs.sourceforge.net/viewcvs.py/tcl/tcl/generic/tclBasic.c?rev=1.27.6.8view=markup This piece alone is not the only obstacle. The more important obstacle is: huge number of *things* affected by the process (each and every procedure must be copied, each and every C-level command, each and every global/namespaced variable, etc. etc.). Doing this on *each* request will just dwarf your CPU on any reasonable production site. For some people it may not be so much of an issue, but yes. Certainly it would seem impossible not to take some performance hit vs the current architeture. Though if your alternative was creating a new interpreter from scratch on each request, it would be a win. Admittedly, people already using AOLserver probably aren't doing that, so perhaps not a useful argument. Another important obstacle: copying commands is not enough since packages do have the freedom to do whatever they like, when loaded. If you were to *properly* address this, then you need to reload the package every time you clone the interp. In which case you needn't copy it's commands... Also, copying commands w/o copying their clientData properly is not going to work. This is how 3.x AS worked and it was plain wrong. Hence the 4.x has completely different (and more correct) approach. This seems to be the killer sadly. For the things I work with, I get the impression that they could be clone-safe... but I'm sure there are plenty of others for whom this would be a showstopper. :) Thanks -- Stuart Children -- 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.
Re: [AOLSERVER] interpreter lifecycle
Zoran Vasiljevic wrote: The Tcl_CloneInterp() is just as simple as: walk over the namespaces get all procs/commands copy them to target interp (copy clientData ptr of commands) get all vars copy them to target (sharing instead of deep-copying Tcl_Objs) and some other small plumbing here/there (errorInfo, errorCode, math functions). It is really no rocket science. The clientData ptr copy is a problem. This is not solvable w/o redefining the Tcl command struct to hold the clientDataDup call. The sharing instead of deep-copying Tcl_Objs is MT-issue which can be solved generally by getting the string rep of the Tcl_Obj and copying the string rep only but maintaining the object type. You are correct, that for general purpose use (especially where threads are involved), Tcl will need to be extended in some way to allow extensions to be aware of cloning. This is similar to how Tcl channels need to be extended to understand the splicing properly between threads. It is possible to do, but the core currently lacks it. As you see, this is nothing very fancy. Yet, I doubt it will be acceptable speedwise, being it in C or not. This I will disagree with. If you can handle it all in C, I think you will save time. A lot will be in the copying itself, but saving any and all parsing is a bonus. Jeff -- 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.
Re: [AOLSERVER] interpreter lifecycle
Andrew Piskorski wrote: On Tue, May 24, 2005 at 02:10:33PM +0100, Stuart Children wrote: in a thread between connections. So the interpreter is *not* re-cloned between requests. Indeed, testing a template that increments a namespace Most definitely not. AFAIK it never has been, ever, in any version of AOLserver. OK. It was Each connection thread that requires Tcl will create a copy of the original interpreter. on http://www.aolserver.com/docs/devel/tcl/tcl-general.html that set me on the wrong initial track - but I realise now that connection thread actually serves many requests. I don't think ANYONE prefers the current design; it is a compromise due to performance and implemention constraints. Jeff Hobbs has pointed out that those implemention constraints should now be fixable, it's just a matter of doing the work. Right. I'd be willing to help coding on this, though my knowledge of TCL internals (from a C POV) is currently a bit lacking. Although to be honest I'm probably looking for a quicker solution than that seems to Just what IS the immediate problem you're trying to solve? I don't think you've ever actually said. Well, there's not a specific issue. I've got a bunch of legacy TCL code that I want to run under AOLserver. At the moment I'm just trying to understand how AOLserver works to ensure I set things up in the appropriate manner and I'm aware of what issues may arise. For example, much of the code makes use of namespaces, but it's previously been run in an environment where each execution gets its own interpreter. I now know that potential assumptions in my code about initial state may not be safe under AOLserver. There's sufficient code that going through it all to check this is not a trivial task. (If globals weren't cleared out either I'd have a nightmare. :]) I'm also simply interested to understand for my own benefit, and so I can develop future code in a manner that best suits AOLserver. Would people would be interested in a seperate first adp error aborts the whole file feature for 4.[01]? From a brief inspection of the No, I'm not interested, but I believe that feature already exists, Jim D. implemented it - or so I seem to recall; I could be wrong. I'll dig further with the CVS sources... Thanks -- Stuart Children -- 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.
Re: [AOLSERVER] interpreter lifecycle
On 2005.05.25, Stuart Children [EMAIL PROTECTED] wrote: For example, much of the code makes use of namespaces, [...] It is likely you will feel pain running that code under AOLserver, because as you discovered, namespace variables do NOT get unset at the end of request processing as part of the cleanup callback. While it would be easy to add the necessary code to clean up namespace variables, I think it isn't being done because doing it could get expensive because, in order to implement it, we'd have to iterate over every single namespace (which could be a large number) then retrieve the list of variables per namespace and unset them. (If globals weren't cleared out either I'd have a nightmare. :]) Indeed. Thankfully, cleaning out the global namespace is generally a fixed cost operation and just had to be done in order to make most scripts work in a sane fashion. I'm also simply interested to understand for my own benefit, and so I can develop future code in a manner that best suits AOLserver. Avoid namespaces. :-) Would people would be interested in a seperate first adp error aborts the whole file feature for 4.[01]? From a brief inspection of the I'll dig further with the CVS sources... Jim's singlescript or whatever it was called will do what you want: the entire ADP gets turned into a single script, and an error anywhere in it will abort the entire script, naturally. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- 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.
Re: [AOLSERVER] interpreter lifecycle
To add my two cents... My thought is to avoid namespace variables. I understand the point that cleaning up after namespace variables would be expensive. However, anything that prevents commands in namespaces from working correctly should be classified as a bug and fixed. Namespaces are an important way to organize code modules. Rob Seeger Dossy Shiobara wrote on 5/25/2005, 8:08 AM: Avoid namespaces. :-) -- 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.
Re: [AOLSERVER] interpreter lifecycle
expensive. However, anything that prevents commands in namespaces from working correctly should be classified as a bug and fixed. Namespaces are an important way to organize code modules. Namespaces are, namespace variables are not. Some packages use them for temporary storage of structures (like httpd and tdom) but they provide their own cleanup methods. I have at points relied on the fact that namespaces don't get cleared out between request (though in Vignette, not AOLserver) and found it rather usefull. Fixing this bug will quite likely break some people's code! Cheers, Bas. -- 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.
Re: [AOLSERVER] interpreter lifecycle
Am 25.05.2005 um 15:39 schrieb Robert Seeger: To add my two cents... My thought is to avoid namespace variables. I understand the point that cleaning up after namespace variables would be expensive. However, anything that prevents commands in namespaces from working correctly should be classified as a bug and fixed. Namespaces are an important way to organize code modules. My 2 cents... Actually, you would like to redesign the way AOLserver treats Tcl code. It has to be sort of module-based, where all modules would have a startup, teardown and cleanup hooks which would then be called by the server machinery at particular points. Now, this is also not something ideal, but would be at least controllable. The current way of wholesale loading Tcl code and synthetizing the introspective script is clumsy, error prone and semi-optimal. The option of walking the namespace tree and matching all variables found there, but not found (or even changed) in the blueprint script is out of the question because it would be plain too slow. Hence it was never actually implemented by anybody. I recall trying to do this myself but abandoned the project at a very early stage. Another idea was to create a fast interp-dup Tcl call which would quickly junk and re-create Tcl interp as_a_whole, but this is/was not MT-aware and hence of little use for AS (or any Tcl-threaded) app. So, this leaves you/us with what we have now. It aint ideal but it works for most of the folks. Admitently, the *entire* beast would need a facelift. Zoran -- 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.
Re: [AOLSERVER] interpreter lifecycle
Bas Scheffers wrote: I have at points relied on the fact that namespaces don't get cleared out between request (though in Vignette, not AOLserver) and found it rather usefull. Fixing this bug will quite likely break some people's code! I too rely on this property of the current implementation in some of my apps so fixing it would break some of my code. However, I found this out the hard way by playing around. If this is not documented somewhere, maby it should be (i.e. on the Wiki and not in the C source where there probably are lots of comments relating to this). -- Olaf -- 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.
Re: [AOLSERVER] interpreter lifecycle
On Wednesday 25 May 2005 06:58, Bas Scheffers wrote: Namespaces are, namespace variables are not. Some packages use them for temporary storage of structures (like httpd and tdom) but they provide their own cleanup methods. Ah, thanks for pointing out this distinction. Package specific cleanup is pretty easy to accomplish, especially considering that AOLserver has ns_atclose. You don't even have to consider the effect of an error killing you cleanup, since it doesn't. I have at points relied on the fact that namespaces don't get cleared out between request (though in Vignette, not AOLserver) and found it rather usefull. Fixing this bug will quite likely break some people's code! Yes, I use namespace variables to hold package startup info. Cleaning them out would not be good. (Since the variables are set during server startup, they are expected to exist in every thread.) tom jackson -- 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.
Re: [AOLSERVER] interpreter lifecycle
I'm inclined to say it either shouldn't be documented, or it should be documented as an undocumented behavior. I don't think this is something that should cause backward compatibility problems later, since there's no good reason for it to behave the way it is now (other than it's too slow to make it behave correctly). Rob Seeger Olaf Mersmann wrote on 5/25/2005, 10:25 AM: Bas Scheffers wrote: I have at points relied on the fact that namespaces don't get cleared out between request (though in Vignette, not AOLserver) and found it rather usefull. Fixing this bug will quite likely break some people's code! I too rely on this property of the current implementation in some of my apps so fixing it would break some of my code. However, I found this out the hard way by playing around. If this is not documented somewhere, maby it should be (i.e. on the Wiki and not in the C source where there probably are lots of comments relating to this). -- Olaf -- 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. -- 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.
Re: [AOLSERVER] interpreter lifecycle
Am 25.05.2005 um 16:37 schrieb Tom Jackson: Yes, I use namespace variables to hold package startup info. Cleaning them out would not be good. (Since the variables are set during server startup, they are expected to exist in every thread.) Tom, It is not the question of deleting all those namespaced vars. Of course they are needed. But some people/software freaks out when for example *additional* variables are added or *existing* ones changed during the processing of the page. This introduces a non-transparent state which is difficult to track and recover from. Hence, in the ideal world, the interp should be left in the pristine state after the page has been processed. This requires a clever garbage-collection mechanism which is IMO too slow to solve in Tcl alone by brute force. Zoran -- 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.
Re: [AOLSERVER] interpreter lifecycle
Robert Seeger wrote: I'm inclined to say it either shouldn't be documented, or it should be documented as an undocumented behavior. I don't think this is something that should cause backward compatibility problems later, since there's no good reason for it to behave the way it is now (other than it's too slow to make it behave correctly). I'd opt for it being documented as an undocumentend / unstable behavior since had this thread not come up, I'd never have thought about if this was the correct way to handle namespace variables. It was just something I discovered and later started to use. There's no question, that if it where possible and feasable to present each conn a clean plate that that would be the correct thing to do. In fact, it would probably in the long run lead to more robust code since there would be fewer global temporary variables. Each package/module could hide them away in its own namespace instead of using akward prefixes (at least that's how I do it now). -- Olaf -- 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.
Re: [AOLSERVER] interpreter lifecycle
Olaf Mersmann said: something I discovered and later started to use. There's no question, that if it where possible and feasable to present each conn a clean plate that that would be the correct thing to do. In fact, it would You'd get PHP, and we all know how blindingly fast that is for having a completely clean interpreter every time... So it's a trade-off, you either get the fastest web-scripting implementation in the business, or you get a dummy proof one. But a little more documentation on the subject would be helpful, but then a little documentation on a lot of subject is still to be done! :) Cheers, Bas. -- 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.
Re: [AOLSERVER] interpreter lifecycle
Bas Scheffers wrote:
Olaf Mersmann said:
something I discovered and later started to use. There's no question,
that if it where possible and feasable to present each conn a clean
plate that that would be the correct thing to do. In fact, it would
You'd get PHP, and we all know how blindingly fast that is
for having a completely clean interpreter every time...
So it's a trade-off, you either get the fastest web-scripting
implementation in the business, or you get a dummy proof one.
You get much more than a dummy-proof one in Tcl, but it is
important to note that you get a clone of an *AOLServer*
interp, not just a Tcl interp. Clean Tcl interps are cheap:
% time {interp delete [interp create z]} 1000
2312 microseconds per iteration
That's on a 1.8ghz P4 running SuSE 9.2, for reference. In
AOLServer, you do a lot more than create a clean interp, you
initialize it with *gobs* of stuff.
I've mentioned it before, but I'll stress it again - it is
possible to improve this speed, possibly dramatically. If
one were to go into the mod-8-3-4-branch that ActiveState
did for Cisco, you will find some interesting core changes.
One of them is an implementation of Tcl_CloneInterp. That
would likely have a large impact, but it wouldn't be trivial
to port to the head and make thread-safe (est 3-4 weeks).
However, I'm sure that a simple, thorough analysis of the
existing framework would provide enough insight into how to
cut the current startup time down without any C changes as
well. Deferring of tasks, lazy loading, etc.
Jeff
--
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.
Re: [AOLSERVER] interpreter lifecycle
Am 25.05.2005 um 21:17 schrieb Jeff Hobbs: I've mentioned it before, but I'll stress it again - it is possible to improve this speed, possibly dramatically. If one were to go into the mod-8-3-4-branch that ActiveState did for Cisco, you will find some interesting core changes. One of them is an implementation of Tcl_CloneInterp. That would likely have a large impact, but it wouldn't be trivial to port to the head and make thread-safe (est 3-4 weeks). Jeff, Are you sure it is possible to low-level clone an interp from one thread and pass it to another? AFAIK, the interp should not jump threads and more importantly reference any Tcl_Obj's from the initial thread where the master interp was created. This seems like a very complex task, if possible at all... Zoran -- 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.
Re: [AOLSERVER] interpreter lifecycle
Zoran Vasiljevic wrote: Am 25.05.2005 um 21:17 schrieb Jeff Hobbs: I've mentioned it before, but I'll stress it again - it is possible to improve this speed, possibly dramatically. If one were to go into the mod-8-3-4-branch that ActiveState did for Cisco, you will find some interesting core changes. One of them is an implementation of Tcl_CloneInterp. That would likely have a large impact, but it wouldn't be trivial to port to the head and make thread-safe (est 3-4 weeks). Are you sure it is possible to low-level clone an interp from one thread and pass it to another? AFAIK, the interp should not jump threads and more importantly reference any Tcl_Obj's from the initial thread where the master interp was created. Each interp is in its own thread. The cloning is actually a low-level deep copy of data structures and Tcl_Objs. The work to be done to ensure it is thread-safe would be making sure the deep copy is deep enough that we don't share any Tcl_Obj's between threads, which isn't allowed (you have to copy them). This seems like a very complex task, if possible at all... Complex, yes, but still possible. Jeff -- 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.
Re: [AOLSERVER] interpreter lifecycle
Am 26.05.2005 um 00:46 schrieb Jeff Hobbs: Complex, yes, but still possible. OK. I will give this a second look... I recall looking at that some time ago already. -- 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.
Re: [AOLSERVER] interpreter lifecycle
Hi Andrew Andrew Piskorski wrote: On Mon, May 23, 2005 at 06:19:21PM +0100, Stuart Children wrote: Certainly trial-and-error does seem to indicate that variables set within a template do not persist across requests (ignoring nsv_*), and What do you mean by a template? An ADP page? An OpenACS Templating System Tcl/ADP pair? Something else? Sorry, I wasn't clear - I meant within the whole scope of handling a particular HTTP request (not including any process/thread initialisation). So that would include perhaps AOLserver handlers, certainly any registered procs, and finally the code that actually gets executed (typically within a .tcl or .adp file) - though I'm primarily concerned about the last of those. that namespace-specific variables set during initialisation are visible during template execution - tying in with what's suggested about cloning a post-startup interpreter's state. The exception being global variables which appear to be completely cleared down before each template is executed - even if they were set during server startup. I'm not aware of any completely definitive docs on those issues. If you find or write some, please do let us know. :) I'll certainly update the Wiki with any facts I can establish for certain, and at the very least point to this discussion. A bunch of stuff about variable persistence and risks of memory leaks in AOLserver is buried throughout this tDOM thread: http://www.mail-archive.com/aolserver@listserv.aol.com/msg08706.html Ah - this indicates that [under the default configuration of connsperthread == 0] namespaces (both their variables and procs) persist in a thread between connections. So the interpreter is *not* re-cloned between requests. Indeed, testing a template that increments a namespace variable and making several requests over a keep-alive connection demonstrates this. What's suggested here: http://www.mail-archive.com/aolserver@listserv.aol.com/msg08733.html is what I was thinking was going on. For me, this would definitely be the ideal way to do things, though with the ability to explicitly modify the base interpreter (to modify: globals, namespaces, etc - nsv_*/ns_eval style). Certainly it would make GC a great deal easier! What are other people's view on this? Are there some who prefer the current system of having some things (eg: globals) cleared out within a thread but others (eg: namespaces) not? I'd be willing to help coding on this, though my knowledge of TCL internals (from a C POV) is currently a bit lacking. Although to be honest I'm probably looking for a quicker solution than that seems to entail. Perhaps Jeff Hobbs can say whether the situation WRT cloning an interpreter within a thread has changed at all? Two other (unrelated) questions: Firstly, it appears that when parsing ADP, if a TCL error is encountered during a %...% block, AOLserver simply logs the error, that block is replaced with an empty string in the output (or the contents of 'errorpage' if set), and execution of the rest of the ADP continues. My question is whether there's a way to configure AOLserver such that execution terminates as soon as a TCL If I remember right, Jim Davidson provided some such method a while back. More info should be in the list archives. Thanks for the pointer. For some reason generic AOLserver queries on Google seem not to return the list archives very often. Anyway, I found the thread starting here: http://www.mail-archive.com/aolserver@listserv.aol.com/msg04685.html - though they're after slightly more than me there, and this 'singlescript' option being implemented: http://www.mail-archive.com/aolserver@listserv.aol.com/msg07867.html which it looks like I could use to achieve the effect I want. The wiki roadmap doesn't cover 4.1 (where the above was merged), so may I ask if there're currently any release targets (either features or time based)? Would people would be interested in a seperate first adp error aborts the whole file feature for 4.[01]? From a brief inspection of the source, it doesn't look like it would be too terrible to implement. I'd be willing to give this a go if the maintainers were likely to take the patch. Cheers -- Stuart Children -- 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.
Re: [AOLSERVER] interpreter lifecycle
On Tue, May 24, 2005 at 02:10:33PM +0100, Stuart Children wrote: in a thread between connections. So the interpreter is *not* re-cloned between requests. Indeed, testing a template that increments a namespace Most definitely not. AFAIK it never has been, ever, in any version of AOLserver. What's suggested here: http://www.mail-archive.com/aolserver@listserv.aol.com/msg08733.html is what I was thinking was going on. For me, this would definitely be the ideal way to do things, though with the ability to explicitly modify :) Digging into the Tcl internals to make fast lightweight interp cloning work for threaded Tcl and AOLserver, well, that's one of those projects which I'd love to do, but which for the forseeable future, I have neither any conceivable need to do so for my paying job, nor the time and dedication to do it entirely on my own time. What are other people's view on this? Are there some who prefer the current system of having some things (eg: globals) cleared out within a thread but others (eg: namespaces) not? I don't think ANYONE prefers the current design; it is a compromise due to performance and implemention constraints. Jeff Hobbs has pointed out that those implemention constraints should now be fixable, it's just a matter of doing the work. I'd be willing to help coding on this, though my knowledge of TCL internals (from a C POV) is currently a bit lacking. Although to be honest I'm probably looking for a quicker solution than that seems to Just what IS the immediate problem you're trying to solve? I don't think you've ever actually said. Would people would be interested in a seperate first adp error aborts the whole file feature for 4.[01]? From a brief inspection of the No, I'm not interested, but I believe that feature already exists, Jim D. implemented it - or so I seem to recall; I could be wrong. -- 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.
Re: [AOLSERVER] interpreter lifecycle
On Mon, May 23, 2005 at 06:19:21PM +0100, Stuart Children wrote: I'm trying to understand the lifecycle of a TCL interpreter in AOLserver, in order to be aware of how variables persist and so avoid issues that might cause - as well as potentially take advantage of any useful features. Certainly trial-and-error does seem to indicate that variables set within a template do not persist across requests (ignoring nsv_*), and What do you mean by a template? An ADP page? An OpenACS Templating System Tcl/ADP pair? Something else? that namespace-specific variables set during initialisation are visible during template execution - tying in with what's suggested about cloning a post-startup interpreter's state. The exception being global variables which appear to be completely cleared down before each template is executed - even if they were set during server startup. I'm not aware of any completely definitive docs on those issues. If you find or write some, please do let us know. :) The simple view of things you already know; it ignores the tricky edge cases and memory cleanup implementation details, and fortunately seems to suffice nicely for everything other than integrating 3rd party tools into AOLserver. In the meantime, here are a few relevant list threads: Jim D. did indeed add extensive Tcl interp comments to nsd/tclinit.c, which he mentioned here: http://www.mail-archive.com/aolserver@listserv.aol.com/msg08776.html A bunch of stuff about variable persistence and risks of memory leaks in AOLserver is buried throughout this tDOM thread: http://www.mail-archive.com/aolserver@listserv.aol.com/msg08706.html Me complaining about / advocating for AOLserver internals design and implementation docs: http://www.mail-archive.com/aolserver@listserv.aol.com/msg08493.html Two other (unrelated) questions: Firstly, it appears that when parsing ADP, if a TCL error is encountered during a %...% block, AOLserver simply logs the error, that block is replaced with an empty string in the output (or the contents of 'errorpage' if set), and execution of the rest of the ADP continues. My question is whether there's a way to configure AOLserver such that execution terminates as soon as a TCL If I remember right, Jim Davidson provided some such method a while back. More info should be in the list archives. -- 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.
