I should also mention that all of threads will be started from Java.

On Fri, Jan 8, 2010 at 6:24 PM, Blake McBride blake@mcbride.name wrote:

Greetings,

I am considering using ABCL as an extension language to a Web server app I have. I know the answer to many of the questions I have in choosing the correct extension language and ABCL seems to fit the bill well. I do have some questions, however.

1. Can ABCL run concurrently in multiple threads without any problems (I

understand the ramifications in terms of my application code)?

2. I would like to have some utility code which is loaded once and shared

by all the ABCL threads. Each thread can then run code that is independent (i.e. they can have the same function names with different definitions). (Perhaps I'd have to use packages for this.)

3. If I am running a lot of different threads will ABCL allow code to be

GC'd when the thread ends (presuming no other thread is using that code)?

4. ABCL seems to have a somewhat heavy startup time. This is okay for the

first time, but I need the threads to start much faster (much less than half a second).

Thanks for the answers!

Blake

On Sat, Jan 9, 2010 at 1:24 AM, Blake McBride blake@mcbride.name wrote:

Greetings, I am considering using ABCL as an extension language to a Web server app I have.  I know the answer to many of the questions I have in choosing the correct extension language and ABCL seems to fit the bill well.  I do have some questions, however.

1. Can ABCL run concurrently in multiple threads without any problems (I

understand the ramifications in terms of my application code)?

It can, and to my knowledge, there are no known multithreading-related bugs.

2. I would like to have some utility code which is loaded once and shared

by all the ABCL threads.  Each thread can then run code that is independent (i.e. they can have the same function names with different definitions).  (Perhaps I'd have to use packages for this.)

Packages are probably the best choice. ABCL as a system is a singleton: all the code is shared across all threads. You can't have two copies of ABCL in the same JVM, or better - you can't have two copies loaded by the same classloader.

3. If I am running a lot of different threads will ABCL allow code to be

GC'd when the thread ends (presuming no other thread is using that code)?

In principle, yes: code, i.e. functions, are Java objects. However, if in one thread you evaluate, say, (defun f () 42), the function won't go away when the thread ends, because a reference to it is kept through the symbol F. In other words, packages and symbols are global, not per-thread, and so is everything that is reachable from a symbol. However, you can use a per-thread package and delete-package it when the thread terminates, for example; in such a scenario, all code installed by that thread will be garbage collected, as long as it's not referenced by someone else.

4. ABCL seems to have a somewhat heavy startup time.  This is okay for the

first time, but I need the threads to start much faster (much less than half a second).

You can start ABCL only once; you don't have to launch it for each thread, and actually you can't do that at all unless you use a fresh ClassLoader for each thread. Just reuse the same ABCL instance: it will automatically detect that it's being called from multiple threads and have its own per-thread state.

I hope I have answered your questions.

Bye, Alessio

Hi Blake,

On Sat, Jan 9, 2010 at 1:24 AM, Blake McBride blake@mcbride.name wrote:

I am considering using ABCL as an extension language to a Web server app I have.

We just put quite a bit of research into getting ABCL to run on Google App Engine, so it would be nice to learn about your experiences. I think ABCL is up to the task.

I know the answer to many of the questions I have in choosing the correct extension language and ABCL seems to fit the bill well.  I do have some questions, however.

1. Can ABCL run concurrently in multiple threads without any problems (I

understand the ramifications in terms of my application code)?

Yes. The same function can be run in any number of threads synchronously.

2. I would like to have some utility code which is loaded once and shared

by all the ABCL threads.  Each thread can then run code that is independent (i.e. they can have the same function names with different definitions).  (Perhaps I'd have to use packages for this.)

You will have to use packages for using the same functions with different definitions: function definitions are a global property of a symbol, but symbols are tied to packages. At this time, there's only a single interpreter meaning that there's no way for different threads to create separate environments.

3. If I am running a lot of different threads will ABCL allow code to be

GC'd when the thread ends (presuming no other thread is using that code)?

Yes. If all references to any object (including code objects) disappear, that object will be GC-ed. We verified that this applies to classes too (classes are used to implement functions). You'll need to destroy the package after you're done using it to eliminate references to the symbols (which in their turn refer to the code). Any function which isn't referred to from a symbol may even be collected during thread execution, if all references disappear.

4. ABCL seems to have a somewhat heavy startup time.  This is okay for the

first time, but I need the threads to start much faster (much less than half a second).

Right. That's no problem. The time used to start up ABCL (roughly 1 second on my system) is used to set up the singleton Interpreter object and runtime environment. After that's been done, threads can be created about as fast as Java can do it.

Thanks for the answers!

Hope they help. If any questions remain - or new ones come up - don't hesitate to ask!

----- Heh. Just when I finish this reply, I see others have already answered roughly the same things. Well, just for posterity I'll just send it. ------

Bye,

Erik.